Table of Tables - PBworksngtsip.pbworks.com/f/TSIP_Planning_Data_Profile_Reqt_v03_.docx · Web viewThe SDP specification describes the meanings and syntax related to transit schedule

Next Generation Transit Service Information Portal (TSIP):

Planning Data Profile (PDP)

(An SDP Extension)

Data Requirements Document

3rd DRAFT

April 30, 2010Updated August 24, 2010

by

Prepared for:

New York State Department of Transportation

DRAFT – PDP Requirements Document 25 August 2010

Revision Table

Filename Publication Date

Version Author Comments

TSIP_Planning Data Profile_Reqt_v001

12/5/09 Preliminary Draft 001

PEO & MD

Preliminary Outline

TSIP_PlanningData Profile_Reqt_v003


PEO Extended outline

TSIP_PlanningData Profile_Reqt_v004a

2/16/2010 Preliminary Draft 004 (a-c)

PEO, NN, LB

Draft boiler plate

TSIP_PlanningData Profile_Reqt_v004d

3/5/2010 Preliminary Draft 004d

PEO, LB

Included Sections 3, 4.1 and 4.2.



PEO Included input from NYSDOT staff


5/5/2010 Draft 010 PEO 1st Draft


8/12/2010 Draft 020 PEO 2nd Draft


8/25/2010 Draft 03 PEO 3rd Draft with examples and QC

document.docx 2


Table of Contents

TABLE OF TABLES................................................................................................................................ 6

TABLE OF FIGURES............................................................................................................................... 8

1 INTRODUCTION.......................................................................................................................... 10

1.1 Scope.................................................................................................................................................... 10

1.2 SDP Overview....................................................................................................................................... 11

1.3 Glossary and Acronyms......................................................................................................................... 14

1.4 References............................................................................................................................................ 14

2 PLANNING DATA OVERVIEW.................................................................................................. 15

2.1 Summary of Concept of Operations for Regional Transit Planning.........................................................15

2.2 Context of Planning Data within the Transit Service Information Portal.................................................15

2.3 Planning Data Typology and Classification.............................................................................................172.3.1 Typology Overview...................................................................................................................................172.3.2 Service Supplied........................................................................................................................................172.3.3 Service Consumed....................................................................................................................................182.3.4 Accessibility..............................................................................................................................................182.3.5 Level of Service (LOS)................................................................................................................................192.3.6 Fare Data..................................................................................................................................................20

2.4 Planning Data Profile Format................................................................................................................ 20

3 DETAILED REQUIREMENTS FOR CROSS-CUTTING SELECTION CONCEPTS.............22

3.1 Transit Network Data Concept -- The Spatial Dimension Data Set Description........................................233.1.1 Definitions................................................................................................................................................233.1.2 Transit Network Taxonomy Described......................................................................................................243.1.3 Transit Network Data Concept Requirements Description.......................................................................253.1.4 Spatial Dimension Data Set Requirements Description............................................................................293.1.5 Examples Related to the Spatial Dimension Data Set...............................................................................42

3.2 Time Period Data Concept – The Temporal Dimension Data Set Description..........................................48

document.docx 3


3.2.1 Time Period Definitions............................................................................................................................483.2.2 Time Period Data Concept and Summary Data Set Requirements...........................................................503.2.3 Time Period Data Concept and Temporal Dimension Data Set Description..............................................533.2.4 Examples of PDP Time Period Data Concepts...........................................................................................57

4 DETAILED REQUIREMENTS FOR PLANNING DATA CONCEPTS...................................62

4.1 Service Supplied Data Concept and Data Set Requirements...................................................................624.1.1 Service Supplied Definitions.....................................................................................................................624.1.2 Service Supplied Data Concept Requirements..........................................................................................634.1.3 Service Supplied Summary Data Set Requirements..................................................................................684.1.4 Service Supplied Data Set Description......................................................................................................77

4.2 Service Consumed Data Concept and Set Requirements........................................................................984.2.1 Service Consumed Definitions..................................................................................................................984.2.2 Service Consumed Data Concept Requirements.......................................................................................994.2.3 Service Consumed Data Set Requirements.............................................................................................102

4.3 Accessibility Data Concept and Data Set Requirements.......................................................................1074.3.1 Accessibility Definitions..........................................................................................................................1074.3.2 Accessibility Data Concept Requirements...............................................................................................1084.3.3 Accessibility Data Set Requirements.......................................................................................................116

4.4 Service Information Comparison Data Sets Requirements...................................................................1184.4.1 Comparison Data Set Requirements.......................................................................................................118

5 VALIDITY CHECKING.............................................................................................................. 120

5.1 Transit Network Data Set Checks.........................................................................................................120

5.2 Time Period Data Set Checks...............................................................................................................121

5.3 Service Supplied Data Set Checks........................................................................................................121

5.4 Service Consumed Data Checks...........................................................................................................121

5.5 Accessibility Data Checks.................................................................................................................... 121

5.6 Identifiers........................................................................................................................................... 121

5.7 Association between Entities..............................................................................................................121

5.8 Code and Enumerated Values.............................................................................................................121

5.9 Other Checks...................................................................................................................................... 121

document.docx 4


6 METADATA................................................................................................................................ 121

APPENDICES...................................................................................................................................... 123

7 APPENDIX A: ACRONYMS AND TERMS.............................................................................123

7.1 A-1: Acronyms.................................................................................................................................... 123

7.2 A-2: Glossary...................................................................................................................................... 123

8 APPENDIX B: REFERENCES AND RESOURCES................................................................123

9 APPENDIX C: PARKING FACILITY DATA CONCEPT DESCRIPTION..........................125

9.1 Requirements Description for Parking Facility.....................................................................................1259.1.1 Parking Facility Definition.......................................................................................................................1259.1.2 Conceptual Data Model..........................................................................................................................1279.1.3 Parking Facility Model Description.........................................................................................................129

9.2 Related Parking Facility Data Types.....................................................................................................1309.2.1 ParkingFacilityType.................................................................................................................................1309.2.2 ParkingServicesType and Association.....................................................................................................1319.2.3 ParkingSpace..........................................................................................................................................1319.2.4 Junction..................................................................................................................................................133

9.3 Reused SDP Related Data Types..........................................................................................................133

10 APPENDIX D: VEHICLE DESCRIPTION DATA CONCEPT DESCRIPTION..............134

10.1 PTV Data Concept and Model Description...........................................................................................134

11 APPENDIX E: ACCESSIBILITY DATA CONCEPT EXTENSIONS.................................141

11.1 adaCompliance_cd Definition..............................................................................................................141

11.2 Connection Segment Extensions..........................................................................................................141

11.3 Passenger Access Component Data Concept Extension........................................................................143

11.4 Amenity Data Concept Extension........................................................................................................144

11.5 Transit Vehicle Extension and Vehicle-Stop Association.......................................................................144

12 APPENDIX F: NYMTC BEST PRACTICES MODEL PDP “PROFILE”.........................146

document.docx 5


12.1 Introduction........................................................................................................................................ 146

12.2 Scope.................................................................................................................................................. 146

12.3 ROUTE Record Format -- TSIP Translation Code Values for BPM...........................................................14612.3.1 ROUTE Mode Translation...................................................................................................................14612.3.2 ROUTE New Mode 1 Translation........................................................................................................14712.3.3 ROUTE Mode ID for Fare Processing Translation................................................................................148

12.4 Time Period Query Description............................................................................................................ 149

12.5 Headway Description.......................................................................................................................... 150

12.6 Capacity Description........................................................................................................................... 153

12.7 BPM Profile Organization and Description...........................................................................................15412.7.1 Metadata File Description..................................................................................................................15512.7.2 File and File Bundle Description.........................................................................................................156

13 APPENDIX G: LIST OF SERVICE INFORMATION DATA SETS..................................157

14 APPENDIX H: SAMPLE DATA FOR SERVICE SUPPLIED EXAMPLES.....................160

Table of TablesTable 1: Current SDP Transit Features by Dimension...............................................................................26Table 2: Requirements for a Transit Polygon Feature Definition..............................................................27Table 3: Summary Data Sets Requirements related to Transit Network..................................................30Table 4: TransitNetwork Data Requirements............................................................................................37Table 5: Description of TransitNetwork Data Concept.............................................................................38Table 6: Description of TransitPathEvent Logical Entity............................................................................39Table 7: Description of TransitPathServiceAssociation Logical Entity.......................................................39Table 8: Data Requirements for Comparison Result Set of Two 2-D Features...........................................41Table 9: Results for Long Island Bus Route N1 Pattern and Stop List........................................................42Table 10: Selection Parameters for White Plains TransCenter Passenger Facilities..................................44Table 11: Transit Stops and Facilities associated with by Location – White Plains TransCenter................45Table 12: Patterns and Routes associated with "White Plains TransCenter" Locations............................46Table 13: Time Period Definitions from the National Transit Database....................................................48Table 14: NYMTC Best Practices Model -- Time Periods Defined from Transit Route System Data..........49Table 15: BPM Time Period Descriptions..................................................................................................49Table 16: Requirements for Time Period Data Concept............................................................................51Table 17: Time Period Requirements for Temporal Dimension Data Set..................................................51Table 18: Summary Data Set Time Period Data Concept Description.......................................................55

document.docx 6


Table 19: Summary Data Set Time Dimension Data Concept Description................................................56Table 20: Custom Interval Data Concept Description................................................................................56Table 21: Schedule Day Data Concept Description...................................................................................56Table 22: DailyPeriod Data Concept Description......................................................................................57Table 23: Example of Implementing a Hierarchical Recurring Time Interval Time Period........................61Table 24: Service Supplied Related NTD Performance Measures.............................................................63Table 25: Schedule Data Concept Requirement Section in the SDP version 1.0........................................64Table 26: Related Schedule Data Concept Section in the SDP version 1.0................................................64Table 27: SDP Transit Passenger Facility Description (from [2])...............................................................66Table 28: Vehicle Passenger Fleet Type Requirements.............................................................................67Table 29: Service Supplied Summary Data Set and Summary Data Concept Requirements.....................70Table 30: Data Description for Service Supply Data Sets..........................................................................77Table 31: RouteModeList Description.......................................................................................................78Table 32: Running Time Data Set Description...........................................................................................81Table 33: Service Headway Data Set Description.....................................................................................84Table 34: Effective Headway Data Set Description....................................................................................85Table 35: Frequency Data Set Description.................................................................................................86Table 36: Service Type Concept Description in Trip List............................................................................87Table 37: Service Span Data Concept Description....................................................................................89Table 38: Capacity Data Set Description...................................................................................................89Table 39: Trip Transfer Data Set Description............................................................................................93Table 40: Transit Facility Transfer Data Set Description...........................................................................94Table 41: Planned Exceptions Data Set Description..................................................................................96Table 42: Service Consumed Related NTD Performance Measures..........................................................98Table 43: NYMTC BPM Service Consumed Measures...............................................................................99Table 44: Passenger Count Requirements................................................................................................99Table 45: Description of Passenger Count Data Concept (Passenger Count List)...................................100Table 46: Example of Sample Data for Passenger Count List..................................................................101Table 47: Average Load Data Set Description.........................................................................................104Table 48: Average Ridership Data Set Description..................................................................................105Table 49: Example data for Average Ridership Data...............................................................................105Table 50: Terms and Definitions.............................................................................................................107Table 51: Part 38 ADA Accessibility specifications for transportation vehicle........................................110Table 52: Typical Equipment at a Rail Station and User’s Needs............................................................112Table 53: adaCompliance Requirements................................................................................................115Table 54: PDP Comparison Result Set Description...................................................................................119Table 55: Summary of Levels and Testing Criteria (adapted from 2, Table 73).......................................120Table 56: Metadata Attributes inserted in PDP Document.....................................................................122Table 57: Requirement Description for Parking Facility...........................................................................125Table 58: Description of Data Elements from ParkingFacility.................................................................129Table 59: Description of a ParkingFacilityType.......................................................................................131Table 60: Description of a ParkingServicesType.....................................................................................131

document.docx 7


Table 61: Description of ParkingServiceAssociation...............................................................................131Table 62: Description for ParkingSpace..................................................................................................131Table 63: Description for ParkingSpaceType..........................................................................................132Table 64: Description for ParkingStatus..................................................................................................132Table 65: Description for ParkingSpaceServicesAssociation...................................................................132Table 66: Description for a Junction.......................................................................................................133Table 67: Description for a JunctionType................................................................................................133Table 68: Enumerated Elements to Support ADA Compliance on PTV...................................................136Table 69: Description of PTV_Type.........................................................................................................137Table 70: Description of Rail_PTV...........................................................................................................137Table 71: Description of Consist.............................................................................................................137Table 72: Description of RSU..................................................................................................................138Table 73: Exampleof PTV_Type...............................................................................................................138Table 74: Example of Rail_PTV................................................................................................................139Table 75: Example of Consist..................................................................................................................139Table 76: Example of RSU.......................................................................................................................139Table 77: Extension to Connection_Seg Data Concept to include Access Attributes..............................142Table 78: Association between BPM Mode and TSIP code values..........................................................147Table 79: Association between BPM New Mode 1 and TSIP Values.......................................................147Table 80: Association between BPM Mode ID for Fare Processing and TSIP Elements..........................148Table 81: BPM Time Period Description.................................................................................................149Table 82: BPM TimePeriod Data Instance...............................................................................................149Table 83: Service Headway (Svc-Hdwy) File Description.........................................................................150Table 84: Service Headway TripList File Description...............................................................................151Table 85: Service Headway TripTimeList File Description.......................................................................152Table 86: Capacity File Description.........................................................................................................154Table 87: Capacity TripList File Description............................................................................................154Table 88: Metadata for BPM Profile Schema Description.......................................................................155Table 89: Sample Data Set used in PDP Examples..................................................................................160

Table of FiguresFigure 1: SDP XML Schema Organization -- High Level Hierarchy.............................................................13Figure 2: Context of Service Information, Summary Data Sets and Summary Data Concepts..................16Figure 3: PDP Data Set Package................................................................................................................21Figure 4: Transit Network Model..............................................................................................................25Figure 5: Relationship between Location and PolygonType......................................................................29Figure 6: Transit Network Summary Data Set Organization.....................................................................32Figure 7: SDP TransitPath Logical Model..................................................................................................34Figure 8: Description of Transit Network One-Dimensional Feature Result Set.......................................35Figure 9: TransitNetwork Entity-Relationship Diagram.............................................................................38

document.docx 8


Figure 10: Description of Transit Network Two-Dimensional Feature Result Set.....................................41Figure 11: Example of a Tool to Select Spatial Dimension Elements.........................................................44Figure 12: Example of Data "By Location" for the White Plains TransCenter...........................................45Figure 13: Example of Summary Data Time Period which extends beyond a single Schedule Version Period........................................................................................................................................................50Figure 14: Summary Data Set Time Period Logical Data Model................................................................54Figure 15: Example of a Time Period Selection Tool.................................................................................60Figure 16: Structure for Mode Data Set....................................................................................................78Figure 17: Structure for Running Time Data Set........................................................................................79Figure 18: Structure for Service Headway Data Set..................................................................................83Figure 19: Structure for Effective Headway Data Set................................................................................85Figure 20: Structure for Frequency Data Set............................................................................................86Figure 21: Structure for Service Type Data Set.........................................................................................87Figure 22: Structure for Span of Service Data Set.....................................................................................88Figure 23: Structure for the Capacity Data Set.........................................................................................91Figure 24: Structure of Trip Transfer Data Set..........................................................................................92Figure 25: Structure for the Transit Facility Transfer Data Set..................................................................95Figure 26: Structure for the Planned Exceptions Data Set........................................................................96Figure 27: Structure for Average Load Data Set......................................................................................104Figure 28: Structure for Average Ridership Data Set..............................................................................106Figure 29: PDP Comparison Result Set Description................................................................................118Figure 30: Parking Facility Logical Data Model........................................................................................128Figure 31: Public Transit Vehicle Logical Data Model.............................................................................135Figure 32: Extension to Connection_Seg for Data Concept Access Attributes........................................142Figure 33: Passenger Access Component and Amenity Data Concept Extensions..................................144Figure 34: Association Entity extending Transit Vehicle Data Concept...................................................145

document.docx 9


1 IntroductionThis document is the Requirements Document for the Transit Service Information Portal (TSIP) Regional Transit Planning Data Profile (PDP). The PDP is an extension to the Schedule Data Profile (SDP), a specification that describes the semantics, syntax and business rules related to the exchange of transit operator schedule and public transit facilities information. Regional transit planners use schedule and transit facility information when developing planning studies and reports; to that end, this PDP extends the SDP by augmenting the transit service data concepts, developing query definitions and summary service information data sets and (performance) measures that support the downstream applications and studies. The PDP, SDP and other transit service information will be stored and accessed from the Transit Service Information Portal. This document specifies the information requirements for downstream planning applications and studies. It does not specify how the performance measures should be generated.

The New York State Department of Transportation (NYSDOT) is leading the development of a multi-agency Transit Service Information Portal (“the Portal”). The purpose of the Portal is to support a robust and flexible range of options for providing key stakeholder groups with useful, comprehensive and high-quality dynamic information about transit service and travel choices in near real time. The Portal will provide operators and planners with an efficient and economical means of supplying standardized transit service data, in published open formats, to each other for coordination of services. Key data elements can also be available to downstream information outlets and for marketing the use of transit. Other potential users include vendors who deploy ITS applications that require transit service data, such as real-time bus arrival systems (e.g., Next Bus), electronic signs at busy transit stops, and a range of signage at multi-modal facilities.

This Planning Data Requirements document for the PDP builds on work done by the 511NY team, TRANSCOM, and all the stakeholders and project team members who developed the SDP.

1.1 ScopeSimilar to the SDP, the PDP describes regional transit planning data requirements that meet the data needs of critical regional transit planning studies, models and applications. Building on the user needs outlined in the Concept of Operations, as well as the functional requirements described in the SDP, this document identifies requirements for selecting and summarizing transit service information. The requirements focus on describing the following:

Raw service data that may be selected (if not already described in a related specification) to generate summary data;

Selection criteria that may be used to parse and summarize (through specific functions, e.g., average, union) the raw service data (metadata description);

Summary data that is generated through the querying process; Business rules and guidance on how to apply the data concept descriptions; and Guidance on how to “tag” the summary sets for use in generating “formal” performance

measures, like NTD submissions and Form 17a.

document.docx 10


The primary sources that drove the needs and requirements for this document are:

Meetings with NYSDOT and with the Transit Planning Technical Working Group. White Paper #1: New York Planning Organizations Inventory Scan White Paper. White Paper #2: Industry Scan of Best Practices and Emerging Technologies for Regional

Planning. "TSIP Concept of Operations Planning Addendum", including Needs and Use Cases that were

developed and revised by the stakeholders, which is referenced in Appendix B.

The purpose of this document is to fully describe the data requirements of the PDP that will be available through the Transit Services Information Portal (TSIP).

1.2 SDP OverviewThe PDP, which is the data profile for regional transit planning information, will need to work in conjunction with the Schedule Data Profile (SDP). The SDP enables transit agencies to exchange transit schedule and related data for use by many different downstream systems. Many planning analyses require access to data described in the SDP.

An exchange format, such as the SDP, enables data representing similar concepts, but derived from different formats, to be described in a normative way, adhering to the same meanings and following specified business rules. The SDP specification describes the meanings and syntax related to transit schedule and transit asset data that meet the requirements of key downstream systems such as a trip planner, timetable generator and temporary schedules (such as detours). The SDP requirements are described by a conceptual data model, and define business rules for documenting and exchanging data using an XML Schema as a data exchange format. To that end, the SDP XML Schema normalizes the format for documenting and checking data to ensure that downstream systems may automatically use the data.

The SDP XML Schema is hierarchical and has a tree-like structure (see ). The root element of the SDP is divided into five branches, characterized by different domains. The main branches are as follows:

Agency Registration: Contains definition information such as for schedule versions/revisions, route definitions, garages/organizational units, locally defined service codes or day types.

Service: Includes trip, block, and timed or recommended transfer information.

Transit Network: Includes patterns and specialized transit paths (like transit only alignments such as track alignments or bus rapid transit guideways).

Transit Gazetteer: Includes place locations defined or associated with transit, including a wide range of locations, such as time points and transfer clusters with pedestrian connections between places. Transit facilities, although a type of transit place, are assigned their own branch because of the complexity of the data model.

document.docx 11


Transit Facilities: Includes stations, plant components at stations and stops, stops, tracks, amenities, portals (entrances / exists), and passenger access components.

Transit service data, that is, scheduled service and coverage of service (locations where transit service is supplied), is available from the SDP.

document.docx 12


Figure 1: SDP XML Schema Organization -- High Level Hierarchy

document.docx 13


The PDP can be considered an extension of the SDP in that it uses the data submitted in the SDP format, and "operates" on that data to derive analytic and summary data sets based on the scheduled service information, facility, and eventually operational or performance data sets. As such, the PDP uses the SDP data, extends it where necessary, and defines standard formats for output when standard operations are applied to the service information. Section 2 describes the classification and taxonomy for the PDP requirements.

1.3 Glossary and AcronymsA table of terms and acronyms are included in Appendix A of this Requirements Document. A few of the most commonly used terms are included here, with the full set in Appendix A.

Term DescriptionConOps Concept of OperationsGazetteer, Transit Describes the places used by transitITS Intelligent Transportation SystemsNTD National Transit DatabaseNYSDOT New York State Department of TransportationPDP Planning Data ProfileRSTWG Regional Stakeholders Technical Working GroupSDP Schedule Data ProfileTSDEA Transit Schedule Data Exchange ArchitectureTSIP Transit Service Information Portal

1.4 ReferencesThe references listed in Appendix B were reviewed or used in the development of this document. The documents listed in the Appendix include the TSIP Planning Concept of Operation Addendum, various Schedule Data Profile (SDP) documents, and other relevant studies related to planning data issues.

References to the citations use the following style [citation number, page number]. For example, the Planning Concept of Operations Addendum is listed as reference 1. A quote or reference to page 35 of the document might appear as [1, p., 35].

document.docx 14


2 Planning Data Overview

2.1 Summary of Concept of Operations for Regional Transit PlanningThe TSIP Concept of Operations for Planning [1], which drives this requirements document, describes the current uses, constraints and applications for regional planning needs. Transit service information needed for regional planning uses were summarized in four sets of operational scenarios that encompassed a broad scope of regional planning activities. The four categories of scenarios included:

Corridor Study Transportation Improvement Program (TIP)/Regional Transportation Plan (RTP)/Air Quality

Conformity Market Study Transit Study / Alternative Analysis / Major Investment Study

Several underlying assumptions relate to the Enumeration of Needs [1, p., 17] that emerge from the Planning ConOps.

(1) The key stakeholder is a regional transit planner. Although the needs of other transportation planners, from service planners to long range planners, are great, TSIP currently collects transit service information including schedule data that meets many regional transit planner data needs.

(2) The summary data needs are based on current descriptions of service information specified by the Schedule Data Profile (SDP) Version 1.1 [2, includes requirements and guidebooks].

(3) Spatial representation and geographic references only refer to transit network features that are specified in the SDP. Transportation spatial features are driven by the map vendor or regional mapping developers who create a transportation base map and insert jurisdiction, landmark and road networks. Since not all transportation networks include the same level of richness, only the data that is submitted by transit providers can be included in the PDP requirements.

(4) Terms such as “transit provider,” “service information,” “passenger access component,” and such use language defined in the TSIP and SDP systems engineering documents. These terms are described and referenced in the Glossary (Appendix A: Acronyms).

2.2 Context of Planning Data within the Transit Service Information PortalWithin the context of transit service data used for regional transit planning, schedule, facility, and operational data involves collecting “raw” or “discrete” data, summarizing it, then combining and analyzing it, and finally generating standard key performance indicators. Figure 2 shows how service data is the foundation of a summary data set and is then used to create performance measures. The diagram shows how the service data is summarized and then may build performance measures. For example, trip descriptions (as defined by Service Information Data Concept) are collected for a monthly

document.docx 15


period (as summarized by criteria and data collections in the Summary Data Set) and used to generate frequencies and headways (as depicted in the Summary Data); route patterns and the number of trips traversing those patterns are used to generate revenue route miles, and the first trip and last trip of each day can be used to generate the span of service, etc.

Figure 2: Context of Service Information, Summary Data Sets and Summary Data Concepts

Although this relationship is obvious, it is important to point this out because the data that is stored in the TSIP is the foundation of the summary data sets and performance measures. To that end, the summary data set must contain the service information needed to generate the summary data. Further, the means by the data is packaged and reported should fully describe how the data was parsed and summarized, its parameters, quality, and methods. Without all this information, the data sets are not as meaningful over the long term. When data about the actual operation of transit service is combined with scheduled service information, the combination can provide even more information for planners. For example, data on boardings / alightings and load information, in conjunction with schedule and facility data produce richer ridership information. When ridership data is compared to vehicle capacity, utilization of service information may be derived. In addition, New York State and the Federal Transit Administration collect some key performance indicators from transit agencies to measure supply, consumption, and level of transit service, as well as safety and security. Although this document describes several New York State and Federal performance measures, it does so to show how the data concepts relate to those measures and can help tag the summary data sets, not to provide guidance or support in meeting Federal and State reporting requirements.

As developed in the Planning ConOps, transit planning data needs drive functionality for a transit planning tool through the types of selections and summaries applied to certain data (such as measuring linear distance). This document does not describe requirements for the analytic methods or operations, rather it details the parameters, quality, and other metadata related to selecting and summarizing raw transit service information. To that end, this document describes the raw data, quality checks, and

document.docx 16

General Performance Measures

Summary Dat

aSummary criteria & data setsSummary Data

Sets

Planned and operational data

Service Information Data Concepts


metadata descriptions, if they are not already described in another Data Profile Requirements document (e.g., Functional Requirements for the Schedule Data Profile). This requirements document describes parameters and quality definitions used to summarize the data (as shown in the “Summary Data” of Figure 2). Many of the summary criteria used to select the data sets are described by time and spatial dimensions in Section 3.

2.3 Planning Data Typology and ClassificationPlanning needs call for the use of raw schedule and operational data to derive summary level transit service information sets. Discrete service information data sets may be segmented by time or geographic dimensions to derive summary data sets. Time and geographic dimensions are the basic selection criteria for creating the summary service information; they are cross cutting criteria that apply to all the transit planning summary information needs that are described in Section 4. These criteria are described in Section 3. Regional transit planning data needs may be classified into several data concept areas in order to simplify their presentation. This requirements document will group the data into four areas: services supplied, services consumed, level of service, and accessibility. In addition, fares or cost to patrons are also an area of interest to planners; that topic will be handled in a separate data profile requirements document.

2.3.1 Typology Overview The planning data concepts associated with the Typology are discussed briefly in Sections 2.3.2 through 2.3.6 and in detail in Section 4 (except for Level of Service and Fares).

Service Supplied (Section 4.1) Service Consumed (Section 4.2) Accessibility (Section 4.3) Level of Service Fares

Each data concept includes the requirements and structure for related service information data concepts (related to the service data) and summary data sets. The document is divided so that the relationship between the raw data and the summary data sets are clearly linked.

2.3.2 Service SuppliedService Supplied is the planned schedule, route, and schedule calendar information. In addition, it describes amenities and services offered at transit facilities and on vehicles. Service data in this category include:

Routes: route by route directions, trips, modes, service types. Transit facilities: amenities, passenger access components, stops, portals. Transfers: Transfer policies and connection opportunities (by operator and between operators,

including coordinated transfers).

document.docx 17


Service Exceptions: Planned exceptions to “regular” service including planned detours and events (special trips).

Vehicle fleet: number, type, and capacity of vehicles.Most of the service data is described in the Schedule Data Profile and some will be described by the Fare Collection Data Profile (FDP). Vehicle capacity is described in this planning requirements document.

With respect to the summary data, though not exhaustive, general summary data sets in this category include:

Span of service Headway / frequency of service Running times (from schedule) Transfers occurring between routes and between modes at transfer clusters (e.g., centers) Service type of routes that serve each stop Transfer fare in effect for transfers at each stop Amenities (by amenity type) at each transit stop Comparisons of service information from different time periods

o New serviceo Eliminated serviceo Expanded serviceo Changed service

The performance measures that may be derived for this category include several NTD parameters including daily time periods (i.e., AM / PM Peak, typical day, average weekday/Saturday/Sunday). This category only includes scheduled service supplied. To that end, NYSDOT Form 7a reporting measures may be completed. Care should be taken in using the service data to create NTD measures;according to NTD, service supplied encompasses the amount of service scheduled or actually operated. Service supplied is measured in vehicles, miles and/or hours that were operated. This data category only covers scheduled (not operated) service.

2.3.3 Service ConsumedService consumed refers to transit services used by passengers. As defined by the NTD, service consumed is the amount of service actually used by passenger and is measured by unlinked passenger trips and passenger miles.

Service data in this category includes passenger counts, including boardings / alightings and loads

With respect to the Summary Data, though not exhaustive, general summary data in this category includes ridership (passenger counts), average boardings/alightings and load.

Some performance measures that use this data include passenger miles traveled (PMT), unlinked passenger trips (UPT), average trip length, and load factor (volume to capacity ratio).

document.docx 18


2.3.4 AccessibilityThe term “accessibility” has many different meanings to different users of transit. The most obvious and critical definition is the one that implies conformance to the Americans with Disability Act (ADA). Another common definition used by transit planners is how easily, i.e., time and number of transfers required for a person to get from point A to point B using transit. Useful accessibility measures, let alone the raw service information, necessary to realistically determine the supply, consumption, and level of service (reliability) associated with accessibility is almost non-existent. For example, how many transit agencies include information on the number, internal dimensions, and door opening width of elevators that serve a platform, bay or dock in a transit station (and their reliability)? How many include information on lighting, pad condition, and visual aid locations (e.g., Braille instructions) at stops? How many define pedestrian paths, distances and times from parking to platform? Accessibility begins to define the data concepts and elements needed to build comprehensive information to support planners and customer information services.

The service data will include information on:

Accessible Component1 Supplyo For transit facilities and stops, including inventory information about passenger access

components and obstacleso For transit vehicles (rail, subway and bus), including inventory information about

passenger access components and obstacles Accessible Components Consumed

o Usage of ramps, lifts, passenger access componentso Complaints, etc.

Level of Service o Reliability of information of passenger access components

2.3.5 Level of Service (LOS)Level of service is characterized as service quality, service reliability, travel speeds, and schedule variability. According to NTD, the level of service is characterized by “operational conditions within a traffic stream and their perception by motorists and passengers. The description of individual levels of service [may be described as] …speed and travel time, freedom to maneuver, traffic interruptions, and comfort and convenience.” [2, NTD Reporting Manuals S-20, FFA-10]

Generally, LOS data is described by travel time and headway variability information, that is, actual operational data relative to schedule service information. The types of data sets needed to generate the key performance measures include:

On-time performance – schedule, route variability / reliability o Travel speedo Actual travel timeo Missed trips (pullouts)

1 A Passenger Access component is equipment that moves people from place to place, like an elevator, escalator, ramp, lift or moving walkway.

document.docx 19


Reliability of frequency of service, especially for transferso Transfer timeo Average wait time at stop

Reliability of passenger access components (elevators, escalators, moving walkways) Incidents that disrupted service

For the purposes of the planning data profile, scheduled service information is described in the SDP. Operational data is not yet described or collected by the Portal. Many of the data sets related to scheduled service information are discussed in the Service Supplied planning category. No additional data sets are described for the LOS category in this requirements document.

2.3.6 Fare DataThe fare data, described in the Fare Collection Data Profile Requirements document, will include regular and discounted fare categories, fare transfer costs (within and between providers), and fare outlet information.

2.4 Planning Data Profile FormatA Planning Data Profile (PDP) should be designed to provide sufficient details about a Transit Provider’s service information to process and calculate key planning measurements needed by regional transit planning studies. A regional planner typically needs only a segment of an operator’s service information; the segment is usually constrained by geographic region (such as a corridor) and a temporal dimension (such as the weekdays over the last month). The spatial and temporal dimensions must be flexible so that a planner may select the appropriate service information related only to the desired region and time periods. Finally, key performance terms such as capacity, headway, and ridership are based on processing “raw” service information into meaningful measures. The ConOps process indicated that planners need the raw schedule and operational data, parsed and bundled, so they can process it using their own algorithms. The time, spatial and raw service information constitutes three different data sets. The time dimensional data set specifies the time period for which the service information applies; the spatial dimension data set specifies the transit network over which the service information applies; and the “planning” data set applies to summary data set requested by the planner. Together, these three data sets complete the PDP “package.” Each data set is composed of “data concepts.” Using the SDP definition, a Data Concept is:

“Any of a group…referring to abstractions or things in the natural world that can be identified with explicit boundaries and meaning, and whose properties and behavior all follow the same rules.” [2, p., 28]

The time dimension data concepts relate to describing time periods that are used to select transit service information. The spatial dimension data concepts relate to transit features and the transit network, as well as other geographic features. Finally, the planning data set includes service information data concepts, many of which are described in the Schedule Data Profile [2]. In addition to the SDP data concepts, the planning data set also describes several planning data concepts that were identified in the Planning ConOps. The transit planning data concepts are only one approach to

document.docx 20


summarizing service information, and to that end the specific equations used to generate the values are described in this document. Tthe raw data used in the calculations are also included in the data set.

An abstract representation of the three data sets of the PDP is illustrated in Figure 3. The Spatial Dimension Data Set contains the selection of transit network elements or the desired region (e.g., corridor); the Temporal Dimension Data Set contains the selection of time periods – a hierarchical structure that may contain a larger frame with recurring periods within it; and finally, the Planning Data Set details “raw” service information that may be used to process a desired performance measure.

Figure 3: PDP Data Set Package

The spatial and temporal dimension data sets are cross cutting because they can be used to select any planning data set. Related time and space dimension data concepts and data set requirements are described in Section 3.

The planning data sets meet the diverse needs of regional transit planners related to service information described by one or more SDP family of data profiles2. The requirements associated with the planning data sets are described in Section 4. Furthermore, Section 4 is divided into four parts that relate to the planning data concepts described in Section 2.3, Planning Data Typology and Classification.

2 For example, the Schedule, Fare Collection, and Real Time Status Data Profiles

document.docx 21

PDP Result Set

Spatial Dimension Data Set

(Section 3.1)

Temporal Dimension Data Set (Section

3.2)

Planning Data Set (Section 4)


3 Detailed Requirements for Cross-Cutting Selection ConceptsA transit planner may request a summary data set for a specific purpose. A set of criteria may restrict the selection of the service information to specific geographic areas, time periods (such as the spring schedule version), an agency’s service area, or a high-volume corridor. The major interest to this requirements document is the selection criteria that result in the summary data set. The selection criteria are bounded by dimensions of time and space. These are the cross cutting data concepts that are used for selecting transit service information. Typically, a transit planner will select or draw a polygon around an area, then she may identify the time period by range of years, quarters, months, days (day types) or discrete periods during a day. The bounding characteristic of a selection is only the first step in creating a transit service data set. The time and geographic dimensions drive the attributes that are attached to the transit network (e.g., frequency of service for a route; boardings / alightings by stop) or are available during the time period (e.g., schedule version, AM peak, weekday, or monthly).

This section describes the geographic dimension selection criteria as “Transit Network” and temporal dimension as “Time Period” data concepts. Because these selection parameters are critical to understanding the value and content of the information, they need to be captured and included in the summary data set. Although the query interface is not defined, the selection parameters that should be included in the result set are critical to defining the Planning Data Profile (PDP).

The selection criteria will need to be defined both for the selection action (such as a “point in polygon” function) as well as to document the parameters of the action (the dimension of the polygon) that are associated with the resultant data set. Also, because geography and time are used to describe transit service information such as schedule version or route segment, these transit concepts overlap with general spatial and temporal dimensions. As such, both general time and spatial dimensions and transit concepts for the transit network, places, and time periods will be described for selecting service information.

In addition, in order to meet the temporal and spatial elements that are needed by transit planners, this document also describes requirements for new and expanded Transit Network and Time Period transit data concepts.

Section 3 includes two parts to cover the two key selection dimensions -- Transit Network and Time Period. Each part is organized as follows:

Definition(s) and taxonomy associated with the “dimension” including transit oriented categories

SDP and New Data Concept Requirements related to the Dimension Typeo Related to transit domain dimensions (that can be used for selecting service

information)o New and enhanced SDP Data Concepts that should be described (the detailed

description are typically included in an appendix)

document.docx 22


Summary Data Set Requirements related to the Dimension Typeso Organized by taxonomy or category of dimensiono Includes types of analytic methods or operational parameters used to select and

summarize dimension (e.g., count the number of stops or calculate number of days) Examples of how to implement the requirements

3.1 Transit Network Data Concept -- The Spatial Dimension Data Set Description

This section discusses geographic information related to transit service. Location information is typically used as a parameter to parse and summarize transit service information. Transit service may be selected by transportation or other specialized geographic feature in addition to transit spatial elements. The transportation spatial element is typically driven by the map vendor or regional mapping developers who create a transportation base map and who insert jurisdiction, landmark, road networks, and related features. Since not all transportation networks include the same level or richness of detail, this section only describes transit features (events and places) and network data that are known to be defined by the Schedule Data Profile and other TSIP data profiles.

3.1.1 DefinitionsThe definitions contained in this section are supported by the transportation geographic-spatial community. Where available, definitions from the Schedule Data Profile Functional Requirements Document [2] are used.

Transportation Network DefinitionThe Transportation Network is “the set of transportation features participating in a set of topological relationships that define an uninterrupted path through the transportation system.” [5, p., 7-5] This can include roads, rail, pedestrian, and bicycle facilities.

Within the context of the transit domain: “The transportation network is the representation of the road and other modal network over which public transportation conveyances travel.” [2, Section 5.1.5, p., 118]

Transit Network DefinitionThe Transit Network is the set of transit features participating in a set of topological relationships that define paths through which transit service is provided. The transit network is composed of linked transit paths of a transit route in each route direction. Pieces of the transit network include route segments, track alignments, paths between two transit features (such as timepoints, stops, or facilities).

Transit Feature Definition“Transit Features are objects that represent real world public transport phenomena.” [5, p., 7-5] Some examples of transit features include transit stops, transfer centers, and parking facilities.

A feature is an “abstraction of real world phenomena” [5, p., 7-5; referenced from ISO 19101] that may be represented by a geo-reference.

document.docx 23


Transit Gazetteer Definition“A Transit Gazetteer is a geographical dictionary and reference for information about places and place-names associated with a specified data set such as the SDP document or [TSIP] registered schedules, landmarks, or other places of interest related to the transit network.” [2, p., 32]. The Transit Gazetteer is sometimes referred to as the Location Table.

SDP Feature List DescriptionThe SDP includes a Location Table that lists all the spatial features contained in each SDP document. The table includes a field that lists the type of feature instance (featureType). The valid values, and thus the types of features that are supported by the SDP [2, p., 67 on feature type] include:

Transit Facility Timepoint Transit Stop Transfer Cluster Portal (to a transit facility) Amenity (at a transit stop or facility) Passenger Access Component (in a transit facility) Physical Point (related to the transit system) Event (along the transit network) Point of Interest

3.1.2 Transit Network Taxonomy DescribedThe Transit Network taxonomy illustrated in Figure 4 shows the data, summary and performance categories for the Transit Network that is modeled by the PDP (depicted in Figure 2). The most basic data concepts are the transit features that cover the three different spatial dimensions (0-point, 1-polyline, and 2-polygon). These are the features that may be selected and inserted into a spatial data set. The planner may use a transit, transportation, jurisdictional or custom-defined feature (e.g., fare zone) to generate a target feature (data) set, such as city boundary to identify all the bus stops contained within the city jurisdiction or a route alignment to list all the pattern variations. The entries in the spatial data set (i.e., feature set) may then be used to summarize the quantity or measure the linear distance of the features in the set. Figure 4 shows how the data concepts are used to build the data sets, and how the summary planning measures are derived from the feature set.

document.docx 24


Figure 4: Transit Network Model

3.1.3 Transit Network Data Concept Requirements DescriptionThe transit network and features (data concepts) that may be included in the spatial data set consist of physical places, topological features, and polygons that compose the transit system. The SDP describes many of the features that may be used by planners to summarize transit service information. Using geographic categories, transit features may be grouped into three classes:

Zero dimensional places (or points) [0-D]

One dimensional segments (polyline or edges) [1-D]

Two dimensional areas (polygon) [2-D]

Table 1 shows the fields that define the basic geographic classes. In the table, the header lists the three classes of features, the second row lists the data structure that represents the spatial feature, and the third row contains all the transit service elements that may be used as a spatial reference. As listed in the table, a two-dimensional feature is typically summarized as a “centroid” or zero dimensional feature and is described in the SDP Location table. The specification allows for two dimensional representations based on the Geographic Markup Language (GML) format – PolygonType, (although, there are currently only two SDP elements that are defined as a polygon).

document.docx 25

Quantity of features (e.g., number of stops)Revenue MilesDistance between servicesetc.

Sum

mary

Planning

Data

Transit Feature Sets[0-D, 1-D, or 2-D]Comparisons between feature setsSpatial Data Set

Transit Features [0-D, 1-D, 2-D]Transit Feature Data


Table 1: Current SDP Transit Features by Dimension

0-dimensional (point) 1-dimensional (polyline) 2-dimensional (polygon)Location (key = locationID) TransitPath (key =

tranPathID)[all SDP 1-D features are directed]

PolygonType[includes centroid which is defined in Location]

Amenity Depot PassengerAccessComponent Portal Timepoint TransferCluster TransitFacility TransitStop

Location is referenced by the following transit service elements: Block (begin and end points) and

BlockTimes TransferClusterName and cluster of

stops ConnectionSegment (beginning and

end points) Trip (begin and end points) and

TripTimes Pattern and EventList

(transitPointEvent) Transfer Event (guaranteed) and

EventConnections

Block (blockPathEvent) Pattern

(transitPathEvent) Track

Depot (depotServiceArea)

Location (geometry)

The transit feature requirements are contained in the SDP Functional Requirements Document [2, Sections 4.5 and 4.6, pp., 64-75]. The SDP data requirements (i.e., attributes and business rules) associated with each of these features are also described in the SDP Functional Requirements Document.

Several new or extended (SDP) data concepts are required to meet the needs of the transit planner. The new and extended data concept requirements include:

Parking facility PolygonType (extension)

The requirements related to these data concepts are discussed in Sections 3.1.3.1 and 3.1.3.2.

document.docx 26


3.1.3.1 Parking Facility Data RequirementsAlthough the Amenity element includes a type for park and ride lots owned by operators, the explicit set of attributes associated with a parking facility data concept is not defined in the SDP3. The Web Data Maintenance System (WDMS) [11] describes attributes for parking, and its model has been adapted to describe this parking facility data concept. Generally, transit planners require information related to the access and capacity of the parking facility. While not all the attributes contained in the parking data concept are needed for the planning data profile, the requirements support other downstream applications of the Schedule and Fare Collection Data Profiles.

A similar model to the transit facility model found in the SDP is applied to the Parking Facility Data Concept. A detailed description of the requirements may be found in Appendix C: Parking Facility Data Concept Description. The model includes information on capacity by vehicle type including bicycles and electric charging stations; parking amenities, walking and passenger access components between the transit and parking facilities (e.g., bridges, elevators); connections between the parking facilities and road network, including gates, entrances, barriers and restrictions.

3.1.3.2 Transit PolygonType Data RequirementsAlthough the SDP has several two-dimensional features, the PolygonType should be updated to conform to the Keyhole Markup Language (KML) Polygon geometry description promulgated by Open Geodata Interoperability Specification (OpenGIS), used by GoogleMaps, and supported by major GIS tools. KML documentation on polygon may be found at:

[http://code.google.com/apis/kml/documentation/kmlreference.html#polygon]

The data concept requirements for a transit feature defined as a PolygonType are described in the next few sections.

Requirements Description for a Transit PolygonType FeatureA transit polygon feature should contain the information outlined in Table 2.

Table 2: Requirements for a Transit Polygon Feature Definition

# Requirement Name Description1 Unique identification and

classificationEach 2-D geometry object is designated by a unique identifier.

2 Polygon transit feature class Each 2-D geometry object is classified as a transit feature type. A transit feature may include: transit facility, parking facility, depot, service area, fare zone, and others as enumerated.

3 Name and description Each transit 2-D feature is associated with a name and description, such as fare zone 1 or Rockland County Transit Service Area.

4 Owner An area belongs to the authority that designated it. For example, the owner of a census tract is Census (USDOC).

3 Because the SDP did not contain functional requirements for parking facilities, they are defined here in the PDP.

document.docx 27

http://code.google.com/apis/kml/documentation/kmlreference.html%23polygon


5 centroid -- locationID Each 2-D feature may be associated with a single point or centroid.

6 Linear Ring and Coordinates A polygon is composed of an ordered set of coordinates. The KML Polygon element includes an outer boundary and an inner boundary (thereby enabling “doughnut” shapes).

7 Measure: area and circumference

A unit of measure of the polygon may be area or extent of the surface or the ring that bounds the 2-D object. The area units may be described in units of square feet, meters, or miles. The linear units around the polygon border may be described in units of feet, meters, or miles.

The TSIP data profiles describe two specific types of transit polygon features:

Service area Fare zone

Service area and fare zone are defined below.

Service Area DefinitionA service area is a transit polygon feature that describes the physical boundaries and area in which transit service is provided by a transit operator. The data requirements associated with the generic polygon description meets the needs of the service area requirements.

Fare Zone DefinitionA fare zone is a transit polygon feature that describes the physical boundaries and area in which a fare cost is associated based on the provision of service through it, or boarding and/or alighting at a transit stop within its boundary.

The fare zone is typically associated with a set of transit stops that are contained in the fare zone. A more complete description of Fare Zone will be included in the Fare Collection Data Profile [3].

Transit PolygonType Model DescriptionThe transit PolygonType is related to the Location table as shown in Figure 5. Currently, the Location table references a string that contains an ordered list of coordinates (based on GML polygonType definition). The KML augments the description with a description of the geometric object’s extrusion (relationship to the vertical), tessellation (whether the object follows the terrain), altitude mode (describes how to interpret altitude in the coordinates field), as well as the outer and inner boundaries of the polygon. The complete description is available at [6].

KML goes on to describe several business rules related to the Polygon description as follows:

“A Polygon … by an outer boundary and 0 or more inner boundaries. The boundaries, in turn, are defined by LinearRings. When a Polygon is extruded, its boundaries are connected to the ground to form additional polygons, which gives the appearance of a building or a box…

document.docx 28


The <coordinates> for polygons must be specified in counterclockwise order. Polygons follow the “right-hand rule”, which states that if you place the fingers of your right hand in the direction in which the coordinates are specified, your thumb points in the general direction of the geometric normal for the polygon.” [6]

Figure 5: Relationship between Location and PolygonType

3.1.4 Spatial Dimension Data Set Requirements DescriptionSpatial dimension data sets are characterized by selecting, grouping and summarizing Transit Feature data. The functional requirements to select and generate the data sets are included in the Portal System Requirements Document [7]. For example, a transit planner may want to request information about effective headway applied to a corridor. First the planner must select the corridor and find all the patterns (transit network features) that are contained in the polygon. The corridor may contain patterns from several routes, but only part of the patterns. The effective headway of all the route patterns differs from the service headway of just a single route pattern. So the transit planner must select the patterns (and related route segments) for which they require the planning attribute. Once the patterns and route segments are selected4, then the service (trip) information can be selected, that is, once the patterns are selected, then the request for effective headway information may be selected. The first step or analytic method that is applied to select the transit network that falls within the corridor is called the “line in polygon” function. The result set of this method is a list of route segments and related routes and patterns that fall within the boundaries of the polygon. Note that this section only discusses the parameters selecting and reporting the spatial dimension or transit network data set. Section 4 deals with describing transit service information that applies to the spatial dimension data set.

4 Information on selecting the time dimension is discussed in the Section 3.2.

document.docx 29


Furthermore, this section includes only the data requirements associated with the transit features and their attributes, not the algorithms that are used to bound the transit features (e.g., points in polygon), measure linear distance, or count the quantity of passenger facilities.

The Spatial Dimension Data Set requirements are summarized in Table 3. In the table, the header row – Spatial Dimension – contains the three spatial dimensions related to location: point (0-D), polyline (1-D), and polygon (2-D). The second row – Spatial Reference – lists the keys used to identify or index each feature within the spatial dimension category. The third row contains a set of operations or bounding selection criteria that may generate additional transit feature sets from the standard set that is currently available. Finally, the last row contains a set of attributes, categorized by “dimension,” that may be derived through a spatial analysis of the defined features or feature set. For example, if a polygon or circle is overlaid on an area, the number of features that are contained within the area will generate a “count” of the total number contained in the intersection of the two polygons. The specification describes the “result set;” it does not specify the method that is applied to derive the elements in the data set. This last row drives some of the core data requirements for the spatial dimension data set.

Table 3: Summary Data Sets Requirements related to Transit Network

Spatial Dimension

0-dimensional (point) 1-dimensional (polyline) 2-dimensional (polygon)

Spatial Reference

Location (key = locationID) TransitPath (key = tranPathID)[note: all SDP 1-D features are directed]

PolygonType (key = geometryID)

Transit Feature Sets

Transit “places” (locations)

Transit “events” and related “transit network” (transit path event or pattern) and locations

Transit System (route alignments from one or more Providers)

Route Segment (e.g., main line) along a corridor (polyline)

Transit Network set

Transit features that are represented as a polygon (2-D feature) based on overlap of Transit Provider polygons

Selection Criteria

Selected polygon (linear ring)

Selected circle (longitude, latitude and radius)

Selected corridor (same as polygon with radius to define buffer)

Selected transit feature; by locationID

Same as Zero Dimension Selection Criteria

Same as Zero Dimension Selection Criteria

Attribute(s) related to Data Set

Count (number of features in data set)

Count (number of features in data set)

Linear distance measure*– without duplication

Count of operator instances Circumference*

Area^

document.docx 30


[Note: each query is unique and has a distinct identification]*Units = [miles, feet, meters]^Units = [square miles, square feet, square meters]

3.1.4.1 Zero-Dimensional Data Set RequirementsThis section discusses the requirements associated with describing a data set of zero dimension transit features, that is, transit “real world phenomena” that are represented by a point. For this selection type, a transit planner may request the parking capacity of stops contained in a corridor. The planner would first select the corridor and then select the stops associated with the parking facilities. The result would include information for each stop along the route (by route direction) and the parking facilities associated with the each stop, all of which are bounded by the designated corridor.

Operations that are used to select zero-dimensional feature sets include:

Select “Point in Polygon” -- Transit places within a polygon (region, area, jurisdiction or other two-dimensional feature);

Select “Point in Circle” -- Transit places within a radius of a circle; Select “Point Adjacent to a Corridor” -- Transit places along or adjacent to a corridor (or

polyline); “adjacent” is defined by a distance or buffer from the corridor, for example all the stops within three-quarters of a mile adjacent to a highway; and

Select by Transit Feature

The set of features within the polygon or adjacent to the polyline may be inventoried and counted. A feature set that is available from one of the three operations should include the following three sets of information:

Selection parameters (criteria) used to define the included area Feature list by feature (element) description (including location reference) Summary count by feature list

The organization of the point feature sets that describe the spatial dimension data set is described in Figure 6. In the diagram, each box describes one or more of the referenced data concepts. The first branch, Selection Parameter Type, shows the selection criteria used to bind the features contained in the data set. The second branch, Feature Set Attribute, includes one or more groups of features selected based on the selection parameter. Since this is the specification for a point, the allowed attributes for the data set includes only a “count”. Finally, the location reference for each place or point is listed in the SDP Location element description.

Note: (opt) indicates that the record is optional.

document.docx 31


Figure 6: Transit Network Summary Data Set Organization

Selection Parameters

PolygonUsing the PolygonType, the polygon shall include the nodes and edges of the area, and identify if the dimensions are inclusive or exclusive of features that fall on the border.

CircleThe circle shall include the center point and the radius that extends the border of the area. The definition should include when the dimensions include or exclude features that fall on the border.

document.docx 32

Transit Network Analytic View

FeatureSet

Selection ParameterType [polygon, circle,

corridor]

(opt) Polygon (PolygonType)

(opt) Circle (point and radius)

(opt) Corridor (TransitPath and

buffer)

(opt) Transit Feature (locationID)

FeatureSet List Attribute: count

Feature Set #1Attribute: count

[1..n] SDP Element Description

Feature Set #2Attribute: count


Feature Set #nAttribute: count


Location (incl agency and sdp reference)


CorridorThe corridor shall include the linear polyline feature that constitutes the path and the orthogonal distance (e.g., a buffer around the polyline) from the corridor used to select the requested features. The definition should include when the dimensions include or exclude features that fall on the border.

Feature SetAny 0-Dimensional transit feature may be requested by the selection parameters. Each feature shall be described by the Transit Provider and SDP document reference, its SDP Feature definition (e.g., Transit Stop, Amenity, etc.), its related transit network feature if needed (e.g., route, route direction and pattern identifiers), and its Location element definition contained in the Location Table. More than one feature set may be included in a feature set list. The order of inclusion shall be alphabetical.

Examples of feature set lists queried in an area or along a corridor may include:

Transit stops and facilities selected by amenity or other plant component type Pattern events (associated with route and pattern identifiers) Agencies providing service in the region

Summary CountA general attribute of the feature set is the count. A count is the number of each unique feature in the data set. Each feature shall be counted and the count included in the feature set.

3.1.4.2 One-Dimensional Data Set RequirementsThis section discusses the result set that is generated when one-dimensional features are summarized in a data set. One-dimensional feature data requirements are associated with the transit network including polylines and directed paths. The types of polyline features currently described in the SDP Functional Requirements include:

Patterns (a directed path from origin to destination over which a transit conveyance travels) Route segments (parts of patterns) – described as a Transit Path Event Passenger access component and connect segment Other modal path (custom path description defined from TransitPath element)

This section describes how a transit planner may select one-dimensional features. A one-dimensional feature set may be selected through the following query methods:

Select transit polylines contained in a transit feature polygon such as a corridor or service area, Select transit features (such as a pattern or route segments) that relate to a named road

network feature (e.g., 5th Avenue), Select transit features that fall within a buffer around a named road (e.g., I-95), and Request related transit polyline features that are contained in or overlaid over a defined space

(such as a custom designed polygon).

document.docx 33


An example of a query might be: what transit routes (by route direction) are associated with a corridor and the effective headway in that corridor. The effective headway information is associated with a set of route segments and is generated after the geographic (and time) dimensions are selected.

The SDP treats a polyline as a directed path and is indexed as a tranPathID. As illustrated in Figure 7, the current SDP description for TransitPath supports bus routes, patterns, route segments, rail lines and tracks, walking and bicycle paths, and other modal paths.

The TransitPath has an origin (from_locationID) and destination (to_locationID). It serves a specific mode and has a linear distance associated with it. It might also have a name. The TransitPath is described by an ordered set of Locations called TransitPointEvent. The TransitPointEvent may keep track of the distance from the TransitPath origin to the current event.

A series of paths may combine one or more TransitPaths into an ordered set of TransitPathEvents. The TransitPathEvent may be associated with a transit network, rail alignment, route segment, or pattern. [2, p., 74]

Figure 7: SDP TransitPath Logical Model

The basic transit network feature applies to a route (by route direction or pattern). As listed above, transit network information may be selected by a pre-defined or custom polygon (similar to the selections in defined in the Section 3.1.4.1). Several operations may be conducted to select one or more one-dimensional transit features. These include:

Select by Route (specify by pattern or route direction); Select by Agency (includes the entire Transit Network); Select “Polyline(s) in Polygon” -- Transit network elements within a polygon (region, area,

jurisdiction or other 2-dimensional feature); and

document.docx 34


Select “Polyline(s) Adjacent to a Corridor” -- Transit polylines (route segments, patterns, modal paths) along or adjacent to a corridor (or polyline); “adjacent” may be defined by a distance or buffer from the corridor, for example “route segments within three-quarters of a mile adjacent to a highway.”

Attribute information may be summarized for the polylines in a feature set. These attribute includes:

Calculating the linear distance of a polyline (TransitPath) Finding the union, intersection, or non-intersecting (symmetric difference) representation and

length of two or more polyline features (overlay operation) -- these Overlay Operations are defined below.

In addition, like all feature sets, the count of elements contained in the feature set should also be included. The organization of the one-dimensional spatial dimension data set, selection criteria and data set attribute information are depicted in Figure 8. Note: (opt) indicates that the element is optional depending on the type of operation selected.

Figure 8: Description of Transit Network One-Dimensional Feature Result Set

document.docx 35

Transit Network1-D FeatureSet

Selection ParameterType

(opt) Select TransitPath or TransitPathEvent

(opt) Route

(opt) Agency

(opt) Polygon

(opt) Corridor

ResultSet (TransitNetwork)

[2..more] TransitPath


The operations may be applied to two or more TransitPaths or transit domain Path Events (such as a pattern), or to all the patterns in a route, all the routes associated with an agency, or just the TransitPaths that are described within a polygon. For the case when a TransitPath extends beyond the polygon, the TransitPath shall not be included in the calculation.

Overlay operations may also be applied to a feature set. An overlay operation is defined as follows:

Overlay Operation (Union, Intersection, Symmetric Difference)

Definition: “The combination of several spatial datasets (points, lines or polygons) creates a new output vector dataset, visually similar to stacking several maps of the same region. These overlays are similar to mathematical Venn diagram overlays. A union overlay combines the geographic features and attribute tables of both inputs into a single new output. An intersect overlay defines the area where both inputs overlap and retains a set of attribute fields for each. A symmetric difference overlay defines an output area that includes the total area of both inputs except for the overlapping area." [Wikipedia, map overlay, 13 Jan 2010].

The different applications of overlay and their requirements with respect to the PDP are described below:

Union without Duplication: The union operation shall result in a non-duplicative set of all the TransitPaths associated with the designated set of TransitPaths (either by tranPathID or contained a polygon), patterns (of a route), or routes associated with an Agency. The resulting data set is composed of all the unique (directed) TransitPaths (which may not be topological).

Union with Duplication: The union operation with duplication shall result in a description of all the TransitPaths associated with the designated set of TransitPaths (either by tranPathID or contained in a polygon), patterns (of a route), or routes associated with an Agency. The resulting data set is composed of all the (directed) TransitPaths and the number of instances (TransitPathEvent) each TransitPath is referenced by a service component (e.g., Trip through pattern and tranPathEventList, or Block through blockPathList).

Intersection: The intersection operation shall result in a description of all the common Transit Paths associated with the designated set of TransitPaths (either by tranPathID or contained in a polygon), patterns (of a route), or routes associated with an Agency. The resulting data set is composed of all the unique (directed) TransitPaths that meet the intersection operation.

Symmetric Difference: The symmetric difference operation shall result in a description of all the disjunctive (not common) Transit Paths associated with the designated set of TransitPaths (either by tranPathID or contained in a polygon), patterns (of a route), or routes associated with an Agency. The resulting data set is composed of all the unique (directed) TransitPaths that meet the exclusion operation.

Another operation that may be applied to a polyline feature set is the calculation of the linear distance all the paths included in the set. Linear distance is defined below.

document.docx 36


Linear DistanceA path has a measure of distance along the polyline (versus line of sight). Distance is described in two SDP data concepts -- TransitPath and TransitPointEvent -- using explicit elements: “distance” and “distanceFromOrigin.”

The element distance refers to the length of a single TransitPath instance (i.e., the linear distance between two points), while the distanceFromOrigin assumes an aggregate measure of linear distance from the origin of the polyline, through the ordered sequence of each transit path (or point) event, to the current transit path (or point) event. For example, if pattern 1234 contains four route segments with linear distances for each TransitPath of 400, 600, 300 and 400 feet respectively, then the distanceFromOrigin for the third path event (associated with Pattern 1234) would be 1300 feet.

TransitNetwork Data Set RequirementsThe result of these operations on two or more 1-D features is classified as a TransitNetwork.

Definition: A Transit Network is “[a] subset of a transportation network that describes the public transportation characteristics of the base map… A transportation network is a two-dimensional graph of links (or arcs) and nodes, describing network connectivity and not necessarily network geometry (shape) but provides the basis for analytical operations such as pathfinding and flow.” [8, p., 57]

The data requirements associated with the transit network are listed in Table 4.

Table 4: TransitNetwork Data Requirements

# Transit Network Requirement Name

Description

1 Unique Identifier and Name Each 1-D geometry object is designated by a unique identifier.

2 Description Description of the functional value or purpose of the transit network.

3 Total Distance by operation type Based on the operation type [union_nonDup, union_Dup, intersection, exclusion], the total linear distance of the TransitNetwork

4 Number of Transit Paths The number or count of TransitPaths in the TransitNetwork5 Set of Transit Paths The set of designated Transit Paths that meet the operation

type criteria. In the case of union_Dup, the number of each TransitPath should be included as an attribute.

6 Transit Service or Network component to which Transit Path belongs

As an optional information, the service description (block, trip or pattern) associated with the transit path should be included by reference identification (e.g., transitPathEvent, patternID, blockID).

document.docx 37


TransitNetwork Data Concept DescriptionThe logical entity-relationship model for the TransitNetwork requirements are illustrated in Figure 9.

Figure 9: TransitNetwork Entity-Relationship Diagram

The Transit Network Data Concept description is defined in Table 5.

Table 5: Description of TransitNetwork Data Concept

Key Name / Role Name Description / UsagePK transitNetworkID A unique identifier for a transit network defined for a purpose.O transitNetworkName A name used to identify the transit network.M transitNetworkDescription The purpose of the network or a description of the content of the

document.docx 38


network.M operationType_cd An enumerated code that classifies the type of operation used to

generate the transit network attributes including distance, number of instances of each transit path, and associated service components. Enumerated types include: unionNonDup, unionDup, intersection, exclusion. The default is unionNonDup.

M distanceTotal The total linear distance of the combined set of transit paths. For operationType_cd equal to unionNonDup, intersection and exclusion, each transit path distance is only counted once. For operationType_cd equal to unionDup, the distance is a measure of each instance a service component travels along that path.

M transitPath_num The count or number of TransitPaths contained in the TransitNetwork.

Related TransitNetwork Data Concept DescriptionsThe related TransitNetwork Data Concepts include two data concepts. One uses a conceptual entity described in the SDP Functional Requirements document, TransitPathEvent, and the other includes the association field between the service entity (block or trip) and the TransitPathEvent. The logical entity is described in Table 6 and Table 7.

Table 6: Description of TransitPathEvent Logical Entity

Key Name / Role Name Description / UsagePK, FK tranPathID A unique identifier for a TransitPath.PK, FK transitNetworkID A unique identifier for a transit network defined in

TransitNetworkPK seqNo A unique identifier that distinguishes the TransitPath associated

with the TransitNetworkcount The number of instances this TransitPath is found in the 1-D

feature set associated with its use in the network. This field is typically included only when the operation is unionDup. The count must be greater than zero.

Table 7: Description of TransitPathServiceAssociation Logical Entity

Key Name / Role Name Description / UsagePK, FK tranPathID A unique identifier for a TransitPath.PK, FK transitNetworkID A unique identifier for a transit network defined in

TransitNetworkPK, FK seqNo A unique identifier that distinguishes the TransitPath associated

with the TransitNetworkPK, FK blockID or

tripID, patternID, routeIDA unique identifier or multiple identifiers that distinguish the service entity (block or trip).

document.docx 39


3.1.4.3 Two-Dimensional Data Set RequirementsThe two dimension spatial data set consists of results from applying polygon operations. These include:

Select by a transit 2-D feature or features (e.g., fare zones for an agency) Select by “polygon in polygon” – select all the transit 2-D features (of a feature type) contained

in a polygon.

In addition, the following operations may be applied to one or more two-dimensional features in a feature set:

Calculate the area of a 2-D feature; Calculate the circumference of a 2-D feature; Count the 2-D features within a polygon; Find the union, intersection, or non-intersecting (symmetric difference) description and areas of

two or more 2-D features; and Compare two 2-D features (area, circumference, count).

The attributes that may be calculated from the features in the feature set list drive the data requirements for the two-dimensional feature sets. Definitions of attributes are documented below.

Area MeasureDefinition: “Area is a quantity expressing the two-dimensional size of a defined part of a surface, typically a region bounded by a closed curve.” [Wikipedia for Area, 13 Jan 2010]

The area measure shall be described as the square units of a PolygonType. When the PolygonType includes “holes” or excluded areas, only the square units included in the PolygonType shall be included in the measure. Units shall include square miles, square feet, or square meters.

Circumference MeasureDefinition: “The circumference is the distance around a closed curve." [Wikipedia for circumference, 13 Jan 2010]

The circumference measure shall be described as the units around the outer edge of a PolygonType. Units shall include miles, feet, or meters.

Overlay Operation (Union, Intersection, Symmetric Difference)(See definition for Overlay Operation above.)

document.docx 40


Figure 10: Description of Transit Network Two-Dimensional Feature Result Set

The result of these operations on two or more two-dimensional features shall be a PolygonType. The output for the spatial data set shall include the selection parameters and feature set list as depicted in Figure 10. The Transit Feature Set for the polygon type includes a list of sdp:Location and kml:PolygonType records.

Comparison of two Two-Dimensional FeaturesComparison between two 2D features consists of identifying a primary and target feature. The primary feature contains the characteristics to which the target feature is compared. The data requirements for the comparison result set are described in Table 8.

Table 8: Data Requirements for Comparison Result Set of Two 2-D Features

# Comparison Type Name Description1 Overlap This describes whether the primary polygon contains all, part or none

of the target polygon. The extent of overlap may be described as the percentage of inclusion associated with the target polygon.

2 Polygon Measures This compares the area or circumference of the primary to target 2-D features, that is, whether the primary is greater or less than or equal to the target.

3 Container Count This compares whether the count of specified point features in the primary is greater, less than, or equal to the target 2-D feature.

document.docx 41

Transit Network Analytic View2D FeatureSet

Selection ParameterType

Custom Polygon (PolygonType)

Transit Feature (PolygonType)

Feature Set List [attributes]

Transit Feature Set (PolygonType)


The result of the comparison operation is the logical operator value and the operations parameters including designation of the primary and target 2-D features.

3.1.5 Examples Related to the Spatial Dimension Data Set

Collection of Stops along a RouteThe T-Best application5 identifies ridership estimates based on a set of stops in a general area. The Spatial Dimension allows for a user to designate a route, or route by direction and aggregate all the stops along the transit feature. For example, if a user requested the stop information for Route 11 (Groton-White Plains for Bee-line), then the location entries as displayed in the map below for each of the stops (yellow) would be selected and stored in the feature set.

Collection of Patterns for a RouteAlthough a tool is not available to draw each pattern, if a user requested the pattern information, the set of Patterns from the SDP would be delivered. Pattern information is composed of a Pattern element and includes the transit point event and/or transit path event entries. For example, if the Long Island Bus Route N1 Jamaica-Elmont -Hewlett patterns was selected, then the response would consist of the following set of patterns and associated event list as depicted in Table 9.

Table 9: Results for Long Island Bus Route N1 Pattern and Stop ListpatternID routeID routeDirection origin destination

104 3732 first 5 4918105 3732 first 5 4918107 3732 first 5 9108 3732 first 5 9109 3732 first 2 4918110 3732 first 2 4918111 3732 first 2 5112 3732 first 2 9113 3732 first 2 9114 3732 first 2 9119 3732 first 7 4918121 3732 first 7 9123 3732 first 6 9

5

document.docx 42


patternID routeID routeDirection origin destination124 3732 first 4 9125 3732 first 4 4918126 3732 first 4 9101 3732 second 4918 228102 3732 second 4918 225103 3732 second 4918 225106 3732 second 228 225115 3732 second 232 228116 3732 second 232 228117 3732 second 232 225118 3732 second 232 225120 3732 second 230 225122 3732 second 4918 228

Generating a Spatial Dimension for Selecting Service InformationA general type of query may entail identifying a spatial dimension that is used to select effective headway information in a corridor or ridership originating and terminating at a transit center. For example, a transit planner may wish to view the impact on ridership at the Transit Center in White Plains due to new service provided by the TAPPAN ZEExpress. In this case, they may select the Transit Center in White Plains “by Transit Feature,” “by polygon” or “by circle.” The three alternatives are:

By circle: with latitude and longitude of (41.033789, -73.77407) and a radius of half a mile. By polygon: by drawing a box around the TransCenter By transit feature: by selecting the regional “Shared Facilities6” and selecting related locations

The TSIP will include a function to support specifying geographic criteria for selecting transit features upon which service is implemented. An example of such a tool, shown in Figure 11, includes a function to select different feature types such as by location (i.e., point feature type). A proposed operational scenario may work as follows:

Select an agency (or several agencies) Select the request for spatial dimension of feature (0, 1, or 2 dimension) Select query by transit feature or custom feature

o If transit feature, select the feature instanceso If custom feature, draw or input coverage of feature (depending on the selection

method). In the example of the White Plains Transit Center, the 3 selection methods and related selection parameters are summarized in Table 10

The query should result in a set of transit features of the selected dimension. Figure 12 shows the transit point features that are included in the Feature Set result set

6 A shared facility is a regional artifact that describes a multimodal/multi-agency passenger transit facility. Individual transit provider facilities and stops should refer to these regional facilities. [2, Attachment B]

document.docx 43


Figure 11: Example of a Tool to Select Spatial Dimension Elements

Table 10: Selection Parameters for White Plains TransCenter Passenger Facilities

Selection Parameters Selection ParametersBy Circle longitude = -73.77407, latitude = 41.033789

radius= 2556 [feet]By Polygon Use PolygonType:

LinearRing [series of longitude and latitude pairs]By Transit Feature Use Location Element Reference:

sdpDocument = SharedFacilitiesDataProfilesdpAgency = alllocationID = R12longitude = -73.77407, latitude = 41.033789publicLocationDescription = White Plains TransCenter

document.docx 44


Figure 12: Example of Data "By Location" for the White Plains TransCenter

The locations that will be selected include information on transit stops/facilities of five transit providers, listed in Table 11.

Table 11: Transit Stops and Facilities associated with by Location – White Plains TransCenter

Location by Agency TransCenter (regional)

ShortLine TPZ MNR B-Line

locationID R12 817561 13 74 4374featureType transitFacility transitStop transitStop transitFacility transitStoplocationDesc White Plains

Station across from Metro-North Railroad Station

White Plains Bus Center

WHITE PLAINS TRANSCENTER

White Plains WHITE PLAINS RAILROAD STATION

longitude -73.77407 -73.77407 -73.774630 -73.775208 73.775060latitude 41.033789 41.033322 41.033789 41.032589 41.033618

document.docx 45

White Plains TransCenter [locationID =

R12]

CoachUSAlocationID=81

7561

TappanZEExpress

locationID=13

MNR locationID=76

B-Line locationID=43

73


publicLocationDescription White Plains TransCenter

White Plains Bus Center

WHITE PLAINS TRANSCENTER

White Plains WHITE PLAINS RAILROAD STATION

isGeneralized False True True True TruegeneralizeLocation R12 R12 R12 R12

The routes and patterns associated with these stops that will be included are listed in Table 12.

Table 12: Patterns and Routes associated with "White Plains TransCenter" Locations

Routes / Patterns by Agency

TransCenter (regional)

ShortLine TAPPAN ZEEXPRESS (TZE)

MNR B-Line

locationID R12 817561 13 74 4374Record 1patternIDrouteIDrouteDirseqNo

--- 521817556first5

E/1TZEfirst13

32 (Harlem-Inbound)first74000

0079-0A1S0079first1

Record 2patternIDrouteIDrouteDirseqNo

--- X-495 Long Island/east-1817556first5

E/3TZEfirst7

42 (Harlem-outbound)second74000

0079-1A1S0079second5


--- --- E/5TZEfirst10

--- 0080-1A1W0080second7


--- --- W/1TZEsecond2

--- 0081-0A2W0081first13


--- --- W/2TZEsecond2

--- (15 patterns and 7 routes all together)

document.docx 46


3.2 Time Period Data Concept – The Temporal Dimension Data Set Description

Service information may be selected using different time intervals and temporal dimensions within a bounded time period (i.e., January 1 to March 31, 2010). For example, a planner may want to select frequency of service (AM Peak periods on typical weekdays) for the Spring 2010 schedule (schedule version). The Time Period Data Concept identifies a time period (e.g., schedule version) and recurring intervals (e.g., AM Peak during “typical” weekdays) by which service information is selected. It does not define the methods used to summarize planning data or other processing methods applied to the content. Other chapters define the planning data concepts associated with specific service information that falls within these designated time periods.

3.2.1 Time Period DefinitionsSeveral definitions are included that describe time periods. Some of the planning applications, like the National Transit Database (NTD) and NYMTC Best Practices Model (BPM), have very formal definitions for different recurring day types and time periods for a regular service day.

PDP Time Period DefinitionA time period is a range of times associated with a date interval (including beginning and ending times and dates) or types of recurring temporal intervals such as days of the week, calendar periods (daily, monthly, annual), or days relative to other special days (e.g., Thursday before New Year’s Eve).

National Transit Database Definitions and Time Period TypesThe NTD [4, Glossary] includes several definitions for different types of time intervals. These definitions are listed in Table 13.

Table 13: Time Period Definitions from the National Transit Database

Time Period Name

National Transit Database Definitions [4, NTD Reporting Manual Reference S-10]

Weekday AM Peak Period

The period in the morning when additional services are provided to handle higher passenger volumes. The period begins when normal scheduled headways are reduced and ends when headways return to normal.

Weekday Midday Period

The period between the end of the AM peak and the beginning of the PM peak.

Weekday Other Period

The nighttime period after the PM peak and before the AM peak when normal scheduled headways are reduced. This is sometimes referred to as night and owl services.

Weekday PM Peak Period

The period in the afternoon or evening when additional services are provided to handle higher passenger volumes. The period begins when normal headways are reduced and ends when headways are returned to normal.

Atypical Day A day on which the transit agency either does not operate its normal, regular schedule, or provides extra service to meet demands for special events such as conventions, parades, or public celebrations, or operates significantly reduced service because of unusually bad

document.docx 47


weather (e.g., snow storms, hurricanes, tornadoes, earthquakes) or major public disruptions (e.g., terrorism).

Average Saturday

A typical, representative Saturday in the operation of the transit system, weighted to reflect seasonal variations in service.

Average Sunday

A typical, representative Sunday in the operation of the transit system, weighted to reflect seasonal variations in service.

Average Weekday

A typical, representative weekday in the operation of the transit system, weighted to reflect seasonal variations in service.

Days Schedule Operated

The number of days that service was actually operated according to the schedule of service. For non-scheduled services such as demand response (DR) and vanpool (VP), days schedule operated refers to the days when service normally was operated.

Typical Day A day on which the transit agency operates its normal, regular schedule and there are no anomalies such as extra service added for a convention or reduced service as a result of weather.

NYMTC Best Practices Model Time Period TypesThe NYMTC BPM travel demand model time periods correspond to the NTD reporting time periods. The specific time periods -- AM Peak, Midday, PM Peak, Evening, Overnight -- categorize differences in service levels such as headways, ridership, etc. For example, the BPM includes headway values based on the different time periods in the Low Level Sample Data: Transit Route System (flowchart module) listed in Table 14.

Table 14: NYMTC Best Practices Model -- Time Periods Defined from Transit Route System Data

Field Name from Transit Route System Table

Description (Headway / Frequency that is assigned to the Time Period)From [9, pp., 74]

ROUTE ID = Unique Route ID (current convention is that ID is between 1,000,000 & 8,000,000 with first digit equal to File Mode.

HWAY_AM AM Peak Headway in minutesHWAY_MID Midday Headway in minutesHWAY_PM PM Peak Headway in minutesHWAY_EVE Evening Headway in minutesHWAY_NT Overnight Headway in minutesAM Flag = 1 if operated in AM Peak (Not Required)

The specific time period are described in Table 15.

Table 15: BPM Time Period Descriptions

Time Period Name Description (from – to; duration in minutes)From [9, pp., 74]

AM Peak Period 6AM to 10 AM=240 minutes

document.docx 48


Midday Period 10AM to 4 PM=360 minutes PM Peak Period 4PM to 8 PM=240 minutesEvening Period 8PM to 1AM=300 minutesNight Period 1AM to 6AM=300 minutes

The data concept descriptions of these time periods are included in Appendix F: NYMTC Best Practices Model PDP “Profile”, which shows how the SDP and PDP data may be coded to input to the BPM.

3.2.2 Time Period Data Concept and Summary Data Set RequirementsTwo types of Time Periods should be described that accommodates both service type information and temporal dimension data set information. The Time Period for transit service covers time periods that occur within a schedule version or on a daily basis. These include a major time period (such as Schedule Version activation and deactivation dates) and the categories of time intervals such as recurring day types and one-time services that occur during the schedule version period.

For planning purposes a time period may extend beyond the typical service periods, for example, annual ridership. A dimension may be selected as a unit by which to view or compare data from recurring periods (or atypical periods), for example, monthly ridership statistics for typical days) or atypical set of days (e.g., New Year’s Eve from 2007 through 2010); scheduled service from one schedule version period to another; or number of trips scheduled per schedule version over several years. Thus, a time period may contain one or more different time periods.

Although similar, service and summary data set time periods differ in some fundamental ways. Specifically, a summary time period incorporates one or more service information related time periods (schedule version and day type) but may also identify new ways of parsing service and operational information (monthly, recurring periods during a day). Figure 13 shows an example time period for a typical day of Spring schedule periods from 2002 through 2010.

Figure 13: Example of Summary Data Time Period which extends beyond a single Schedule Version Period

document.docx 49

Day type or recurring period (typical day)

Schedule version period (Spring pick)

Summary time period (from 2002-2010)


Although many service information categories already include time periods in their descriptions (e.g., Schedule Version includes activation and deactivation dates, Day Type includes recurring types and specific dates), the general requirements for Service related Time Period data concept are listed in Table16 and the planning data set requirements for time period are described in Table 17.

Table 16: Requirements for Time Period Data Concept

Req’t #

Req’t Name Requirement Description for Service Information

1 Uniqueness and Name

A time period is named or assigned a unique index. A time period name may assume the functionality of the type of time period (see Requirement 7), for example, weekday, holiday, Spring 2010 (schedule version), General Order (number 23487).

2 Effective Period Range

A time period includes a start time and an end time, and is assigned to one or more continuous dates (with activation date-time and deactivation date-time) or recurring types of days.

3 Relative period vs. Date Interval

A time period may be assigned to one or more specific dates or may be assigned to a type of day – weekday, holiday, or schedule day.

4 Type of Day A type of day may be assigned to one or more day(s) of the week or a category of day on which transit service is scheduled such as a holiday.

A type of day may recur during the course of a more extensive designated time period (such as a schedule version).

A type of day may be assigned to a specific date.5 Schedule Day A schedule day may exceed a twenty four hour day, for example a schedule

day may be 36 hours, starting six hours before midnight (of a specific day) and ending at 6 am on the following day.

6 Day of the week A day of the week is Sunday, Monday, Tuesday, Wednesday, Thursday, Friday or Saturday. Weekend and weekday is composed of different days of the week, for example, weekend consists of Saturday and Sunday; weekday is Monday through Friday.

7 Time Period Assignment and Description

A time period categorizes different types of service functions by its time dimension as designated by an authority. The period may be characterized when something changes from one state to another, for example, a specific fare cost may be assigned to a “peak” fare time period, while an “off-peak” fare time period may indicate a lower fare cost.

Table 17: Time Period Requirements for Temporal Dimension Data Set

Req’t #

Req’t Name Requirement Description for Summary Data Set

1 Uniqueness and Name

A time period is named or assigned a unique index. A time period name may assume the purpose of the type of time period (see Requirement 7), for example, monthly ridership statistics, AM Peak headway period, weekly on-time performance for Route 10-trip 1234, daily fare transactions at Fulton Station.

document.docx 50


Req’t #


2 Effective Period

A time period includes an effective period for the purposes of summarizing, comparing or viewing service information that falls within that period. The effective period includes a start and end time and date. Note: This is the period related to the service and operational data sets that are analyzed and whose data are summarized.

3 Description A summary or explanation for the time period.4 Type(s) of

PeriodsA type of time period may be characterized by different time dimensions. The types of periods may be standard temporal time periods or custom ranges; they may recur or be continuous; and they may be combined. The different types include:

Day Type (recurring): weekday, holiday, weekend, average saturday, etc.

General Time Interval (continuous): service version, daily, weekly, monthly, annual.

Custom-Recurring Intervals (CRT): start and end times for recurring times (and dates). This category may be derived from the service information, for example, time period when headways decrease in the inbound direction (e.g., AM peak)

Custom-Continuous Intervals (CCT): for a specific set of continuous days designated by a user; for example time period during street construction or snow storm.

A combination of the types of periods may include the AM Peak periods that occur on Mondays or periods that occur monthly between noon and 1pm (where the effective period is January 1 to Dec 31, 2009).

Typically recurring periods of small increments of time (such as time less than a day) may occur within other small intervals, and so on so long as the interval is fully contained in the larger time period range. The Effective period bounds the Performance Time Period. For practical purposes, no more than two or three time periods should be contained in other time periods.

5 Type of clock A type of clock differentiates between a normal 24 hour day and a schedule day (which may extend beyond a typical 24 hour day). If a schedule day is designated, the start of the day (before midnight of the date) and conclusion of the day (after midnight of the designated date) should be defined with respect to integer seconds (where negative seconds indicates seconds before midnight and seconds greater than 86,400 seconds are describe the time after midnight on the next day).

Note: some service components such as a trip or trips associated with a vehicle assignment may be associated with a schedule day rather than a 24 hour clock.

6 Day Type ‘“A designation for a type of day characterized by one or more properties that affect public transport operations.” [NTCIP 1404:2000]’; [2, p., 103]Typically, a day type recurs during an effective period, such as weekday occurs

document.docx 51


Req’t #


Monday through Friday over a schedule version from the first schedule day of its activation date to the last schedule day of its deactivation date.

7 General Time Interval

A continuous time interval in a recognized time category. Typical categories include: daily, weekly, monthly, annual, and service version.

8 Custom-Recurring Interval

One or more custom or day type time periods that recur over the Effective Period.

9 Custom-Continuous Interval

A continuous period set by the user that defines a custom start and end time and date of the temporal dimension. (Note: this may be the same as an Effective Period when an inclusive date range is designated.)

3.2.3 Time Period Data Concept and Temporal Dimension Data Set DescriptionThe Time Period requirements assume a data model that is described in Figure 14 with the data concepts described in Table 18 and related data concepts.

document.docx 52


Figure 14: Summary Data Set Time Period Logical Data Model

A Temporal Dimension Data Set is one that a user may specify to parse transit service information data concepts. It is composed of a name and description and one or more combinations of Time Dimensions. The Time Dimension is recurring or non-recurring. It is used to segment service information into parts that may be analyzed or compared to each other. The dimensional elements may include one or more service information temporal categories and/or general time interval categories. Related transit service information categories include:

document.docx 53


Daily time category of “schedule day” which defines the length of a day to which service information is assigned.

Daily period which defines recurring time periods during a day by type of day (DayType). These include AM Peak, Midday, PM Peak, etc.

Type of Day category (SDP DayType) that describes the type of service offered on a given day (and by definition “typical,” “atypical” and “average” days described by NTD reporting requirements).

Schedule version interval; by definition in the SDP, this category may also include the schedule revision and route depot version7 activation/deactivation periods.

The general time interval categories include:

A customized time period that occurs during the course of a day from timeBegin to timeEnd (for example, the time that a snow storm occurred).

A general time interval category such as daily, weekly, bi-weekly, monthly, quarterly, or annually.

A customized range of dates from dateBegin to dateEnd.

Note that the default daily period is the standard twenty four (24) hours except when the schedule day is inserted into Time Dimension; the insertion indicates that the daily period is based on the transit provider’s schedule day definition.

Notes on Table 18 through Table 22: PK indicates primary or identifying key (and mandatory field) Non-identifying foreign keys (FK) are not included in a data concept description except

CustomInterval (Table 20). M indicates a mandatory field O indicates an optional field

Table 18: Summary Data Set Time Period Data Concept Description

Time Period Field Names

Key Data Concept Description

timePeriodID PK A unique alphanumeric character for Time PeriodtimePeriodName O A name for the Time PeriodtimePeriodDescription O A short description of the purpose of the time period.authority O The authority or person who designates the time periodeffectiveDateBegin M The starting date and time of the Time PeriodeffectiveDateEnd M The ending date and time of the Time Period

Table 19: Summary Data Set Time Dimension Data Concept Description

Time Dimension Key Data Concept Description

7 See definitions for these data concepts in the Glossary.

document.docx 54


Field NamestimeDimID PK A unique identifier for a Time Dimension. The time dimension associates

(combines) different intervals of recurring and embedded time intervals. timeDimName M The name of the time dimension name.timePeriodType M This is an enumerated type to indicate if the time dimension occurs more

than once over the course of the effective period or not. “recurring” indicates that the dimension recurs on the day type,

time interval or temporal interval (within the temporal interval, schedule version or calendar dates); or

“nonrecurring” indicates that the activity is continuous and occurs only between the beginning and the ending dates and time.

timePeriodID FK, PK From TimePeriod table. This field must be included in this entity.

Table 20: Custom Interval Data Concept Description

Custom Interval Field Names

Key Data Concept Description (including CalendarDate, TemporalInterval and TimeInterval)

customTimeInterval PK A unique identifier for the custom time period specified by a user.dateBegin FK The calendar date when the interval begins.dateEnd FK The calendar date when the interval ends.timeBegin FK The time that the interval begins (the time occurs from the dateBegin,

or if no date is selected, on every day within the effective period).timeEnd FK The time that the interval ends (the time ends on the dateEnd, or if no

date is selected, on every day within the temporalCategory, or if no temporalCategory (or schedule version) is selected, on every day within the effective period).

temporalCategory FK A temporal category that recurs from the first day of the effective period to the last day of the effective period.

Table 21: Schedule Day Data Concept Description

ScheduleDay Field Names


scheduleDayID PK A unique identifier for a schedule day (for a specific agency).agencyID O A unique alphanumeric character for transit provider.timeBegin M The starting time of the schedule day in seconds past midnight of the

schedule day. In some cases, a schedule day will begin before midnight. Midnight is equal to “0”. Seconds before midnight is counted using negative values, e.g., where -60 is equal to 23:00 on the day before the calendar date, -120 is equal to 22:00, etc.

timeEnd M The ending time of the schedule day in seconds. The ending time may be greater than 24 hours, for example, 6 hours after midnight on the day after the date of the schedule day would be 86,400 (seconds since midnight).

document.docx 55


Table 22: DailyPeriod Data Concept Description

DailyPeriod Field Names


periodID PK A unique identifier for a Daily Period defined by a transit provider.periodName M A descriptive name by which the daily period is called, for example

AM Peak or AM Peak FareperiodDescription O The description or purpose of the daily period.inclusive M Boolean: When true (1), the period applies to the specified time

range (timeBegin and timeEnd). When false (0), the DailyPeriod refers to times that are not currently covered by other DailyPeriod descriptions.

timeBegin M* The time in seconds past midnight that the period begins.timeEnd M* The time in seconds past midnight that the period ends.dayType O The dayType_cd (from the SDP) that identifies the type of service day

on which the time period recurs.* These fields are conditional on “inclusive” value being “true.”

The SDP Functional Requirements Document describes the DayType and ScheduleVersion data concept descriptions.

3.2.4 Examples of PDP Time Period Data Concepts

“Average,” “Typical” and “Atypical” DaysAs defined in the NTD reporting manual, an average or typical day is a representative day. An “Average Weekday” may be defined by a dayType that is equal to “weekday” and “weekday-closed.” The concepts would be populated in two tables: one record in Time Period and two records in Time Dimension (for each dayType enumeration).

Time Period Data Values - 1timePeriodID 1001timePeriodName Average WeekdaytimePeriodDescription Based on NTD definitionauthority MTA NYCTeffectiveDateBegin 2010-01-01effectiveDateEnd 2010-12-31

Time Dimension Data Values - 1 Data Values - 2timeDimID 1 2timePeriodID 1001 1001timeDimName Average Weekday Average WeekdaytimePeriodType recurring recurringdayType weekday weekday-closed

document.docx 56


Fare Time PeriodsA Fare Time Period may be described using the DailyPeriod data concept. For example, the side bar shows the peak fare periods on the Metro-North Railroad. The tables show how the fare time periods may be represented using the Time Period data concepts.

Peak fare Time Periods may be represented as a DailyPeriod:

Field name Value #1periodID 1periodName AM Peak Fare Period

Inbound periodDescription Peak fares are charged for

travel to Grand Central Terminal or Harlem-125 Street Station. Peak fares apply to weekday trains that arrive in Grand Central between 5 AM and 10 AM.

inclusive truetimeBegin 18000timeEnd 36000dayType weekday

Field name Value #2 Value #3 Value # 4periodID 2 3 4periodName AM Peak Fare Period

Outbound PM Peak Fare Period Outbound

Off-Peak Fare Period

periodDescription Peak fares are charged for any weekday trains that leaves Grand Central between 5:30 AM and 9 AM.

Peak fares are charged for travel that depart Grand Central between 4 PM and 8 PM.

Off-peak fares are charged at all other times during weekdays and all day Saturdays, Sundays, and holidays.

inclusive true true falsetimeBegin 19800 57600timeEnd 32400 72000dayType weekday weekday

Generating a Series of Recurring Time Intervals for Selecting Service InformationA general type of query may entail identifying a time dimension that is used to query and select service information. For example, a planner may ask for certain service information related to AM Peak periods across the four schedule versions that were implemented in 2009. The time period that is generated only selects service information for the specified time period and lists the raw information.

document.docx 57

Metro-North Railroad Fare Periods Peak and Off-Peak Fare Period Descriptions

Peak fares are charged for travel to or from Grand Central Terminal or Harlem-125 Street Station. Peak fares apply to weekday trains that arrive in Grand Central between 5 AM and 10 AM and that depart Grand Central between 4 PM and 8 PM. Peak fares are also charged for any weekday trains that leave Grand Central between 5:30 AM and 9 AM.

Off-peak fares are charged at all other times during weekdays and all day Saturdays, Sundays, and holidays.


The TSIP will include a function to support selecting and specifying a time period query and documenting the selection criteria (in metadata). An example of such a tool, shown in Figure 15, includes a function to select of the effective period, daily recurring periods, time intervals and schedule version. The tool will only include information supplied by a Data Provider. This example shows manufactured data about a provider in the New York metropolitan area.

Schedule Version Lookup Panel 8

In this example, Long Island Bus uploaded seven SDP production schedules (with additional revisions) to TSIP. The panel shows the schedules that are available to query. There may be other TSIP Data Profiles in the future (for example the Fare Data Profile) that have different versioning periods.

Time Dimension Lookup Panel

The Time Dimension sets the criteria for the Time Period. Time dimension enables the user to select the clock type (schedule day or 24 hour clock) and the effective dates that bound the active time period of the data sets. The effective dates may drive the selection criteria for other panels such as the schedule version panel; for example, when the planner selects the effective dates, only those schedule versions that fall within the dates may be selectable. Alternatively, the effective dates may be inserted automatically by selecting one or more schedule versions.

Daily Recurring Time Period Lookup Panel

The user may view the times that frame the Daily Recurring Time Period (using a mouse-over or other presentation technique), or generate and name a new daily time period. These time periods may be restrained by the day type selected in the Time Interval Recurring Lookup Panel.

Time Interval Recurring Lookup Panel

The Time Interval Lookup Panel defines an interval period to select the data. It is by nature hierarchical. For example, a day type is an interval that recurs in a Schedule Version, and typically multiple schedule versions occur during a year. There are several dozen hierarchical alternatives that a planner may select based on the schedule version and day type. To that end, and in order to enforce the business rule that states that time intervals must be bounded by other time intervals, a tool may implement levels of intervals. For example:

Level 1: A daily recurring peak time period is contained in a time interval such as a “weekday” day type

Level 2: A weekday Day Type is contained in a bi-weekly interval Level 3: A bi-weekly interval is contained in a quarterly interval Level 4: A quarterly interval is contained in an annual interval

8 For the purposes of this example, a “panel” implies a graphic user interface provided by the operational scenario.

document.docx 58


Level 5: An annual interval is bounded by an effective date beginning on January 1 and ending on December 31

As a way to validate the business rules, one may assume that an application checks that the time dimensions and intervals meet certain hierarchical relationships, that an AM Peak falls within a weekday, and week falls within a month, etc.

Figure 15: Example of a Time Period Selection Tool

The values that demonstrate the example above would look like the example in Table 23.

Table 23: Example of Implementing a Hierarchical Recurring Time Interval Time Period

Time Period Data Values - 1timePeriodID 1001timePeriodName ExampletimePeriodDescription Demonstrate hierarchical levels of time intervalsauthority MTA Long Island Bus

document.docx 59


effectiveDateBegin 20100101effectiveDateEnd 20101231

Time Dimension Data Values - 1 Data Values - 2 Data Values - 3 Data Values – 4timeDimID 1 2 3 4timePeriodID 1001 1001 1001 1001timeDimName Daily period and day

type for exampleBi-weekly interval for example

Monthly interval for example

Quarterly interval for example

timePeriodType recurring recurring recurring recurringcustomTimeInterval biw mnth qtrdayType weekdayperiodID 1

Daily Period Data Values - 1periodID 1periodName AM Peak periodDescription Morning Peak periods for inbound tripsinclusive truetimeBegin 18000timeEnd 36000dayType weekday

CustomInterval Data Values - 1

Data Values - 2 Data Values - 3

customTimeInterval biw mnth qtrtemporalCategory biweekly monthly quarterly

document.docx 60


4 Detailed Requirements for Planning Data Concepts

This section is divided into four subsections, with each describing a category of planning data concepts that cover the needs identified in the Planning ConOps. The four categories are:

4.1 Service Supplied 4.2 Service Consumed 4.3 Accessibility

A final part of this section (4.4) covers requirements for describing a data set that compares service information from different time periods.

4.1 Service Supplied Data Concept and Data Set RequirementsThe Service Supplied requirements section covers scheduled service, fleet inventories, and facilities definitions (spatial references and geographic characteristics are handled by the Transit Network (Section 3.1)). This section describes the PDP data concept definitions for the Service Supplied category, as well as descriptions documented by policy reporting needs (e.g., NTD) and downstream applications (e.g., BPM).

Section 4.1.1 defines the scope of the “Service Supplied” category and its context with respect to policy level descriptions;

Section 4.1.2 describes the raw data concepts that are reported by transit providers in the SDP and through new extensions described in this document;

Section 4.1.3 describes requirements for data set summaries that support planning needs; and

Section 4.1.4 describes the formats for rendering the data set “documents” or files.

4.1.1 Service Supplied Definitions

PDP Definition for Service SuppliedAs defined by this document, Service Supplied addresses service needs of current and potential future customers and developing service plans that are translated into deliverable service. It includes schedule data (routes, trips, service types, modes) and current assets related to vehicle fleets and customer amenities.

The majority of data requirements needed to cover service supplied are available through a standard Schedule Data Profile (SDP) document, supplied by a transit provider when their schedule or facilities change or are updated.

NTD Definition According to NTD, “service supplied is the amount of service scheduled or actually operated. Service supplied is measured in vehicles, miles and / or hours that were operated.” From [4, NTD S-10].

document.docx 61


There are three primary measures of scheduled service in NTD as cited in Table 24.

Table 24: Service Supplied Related NTD Performance Measures

Performance Measure NTD DefinitionScheduled Revenue Miles The vehicle revenue miles computed from the scheduled service. It

includes only the scheduled vehicle revenue miles from the whole trip. It excludes deadhead, service interruptions, and special additional services. [4, S-10]

Scheduled Revenue Hours The time when a vehicle is available to the general public and there is an expectation of carrying passengers. These passengers either directly pay fares, are subsidized by public policy, or provide payment through some contractual arrangement. Vehicles operated in fare free service are considered in revenue service. Revenue service includes layover / recovery time. Revenue service excludes deadhead, vehicle maintenance testing, school bus service, and charter service. [4, S-10]

Scheduled Revenue Trips Revenue service that is provided for picking up and discharging passengers on a continuing and regular basis, i.e., “scheduled.” A scheduled revenue trip appears on internal transit agency planning documents (e.g., run paddles, trip tickets and public timetables) [4, R-20]

NYMTC Best Practices Model Service ParametersThe major service supply measures needed by the NYMTC BPM are headway and capacity categorized by route direction, stopping pattern, transit vehicle capacity, and time period. According to the Transit Network Data Coding [9], the descriptions for the two key parameters are:

Capacity“The average hourly capacity (persons / hour) for each pattern in [the time period].” [9, p., 75] where the time periods are described as AM Peak, Midday, PM Peak, Evening and Night (see Appendix D for definitions).

Headway“The average headway [for each stopping pattern] is calculated as the number of minutes in the [time period] divided by the number of [trains or buses] arriving in Manhattan during that period.” [9, p., 74]

4.1.2 Service Supplied Data Concept Requirements The Service Supplied data includes service information such as schedules, vehicle fleet, and passenger facility information. Summary data includes information derived from schedule data, such as trip frequency, headway, running times (derived from trip information), and service capacity parameters. The summary data set requirements are described in Section 4.1.3.

Schedule and Service Type RequirementsRequirements for schedule and service type data concepts are incorporated in the Schedule Data Profile [2]. The needs include defining the routes, trips, trip service types, and transfer opportunities related to

document.docx 62


scheduled service. The SDP addresses those needs. References to the sections that list the major schedule data concepts may be found in Table 25.

Table 25: Schedule Data Concept Requirement Section in the SDP version 1.0

SDP Section # SDP Data Concept Requirements4.2 Transit Agency4.13 Block 4.14 Metadata4.6 Pattern4.4 Route4.11 Schedule Calendar Date4.3 Schedule Version4.10 Timepoint4.9 Transfer Cluster4.12 Transit Feature (Geography/Topology)4.5 Transit Gazetteer4.8 Transit Stop and Transit Facility4.7 Trip / Train

Related data concepts are included in the major Sections. A cross reference to these related transit data concepts are listed in Table 26.

Table 26: Related Schedule Data Concept Section in the SDP version 1.0

SDP Section # Related Data Concept SDP Data Concept4.2 Agency Transit Agency4.8 Amenity Transit Stop4.8 Amenity_Type Transit Stop4.13 Block Block4.13 Block_Event_Time Block4.11 Calendar_Date Schedule Calendar Date4.9 Connection_Seg Transfer Cluster4.11 Day_Type Schedule Calendar Date4.2 Depot Transit Agency4.7 Event_Connection Trip4.8 Facility_Plant_Component Transit Stop4.5 Location Transit Gazetteer4.2 Mode Transit Agency4.7 Note_Association Trip4.7 Note_Entry Trip4.2 Organizational_Unit Transit Agency4.8 Passenger_Access_Component Transit Stop4.8 Passenger_Access_Type Transit Stop4.6 Pattern Pattern

document.docx 63


SDP Section # Related Data Concept SDP Data Concept4.8 Plant_Component Transit Stop4.8 Platform_Track Transit Stop4.8 Portal Transit Stop4.13 PTV Block4.5 Relative_Location Transit Gazetteer4.4 Route Route4.4 & 4.11 Route_Depot_Version Route and Schedule Calendar Date4.4 Route_Direction Route4.4 Route_Grouping Route4.4 Route_Grouping_Type Route4.11 Schedule_Calendar_Date Schedule Calendar Date4.11 Schedule_Revision Schedule Calendar Date 4.11 Schedule_Version Schedule Calendar Date4.11 Schedule_Version_Type Schedule Calendar Date4.2 Service_Area Transit Agency4.8 Status Transit Stop4.8 Status_Code_Type Transit Stop4.7 Time_Event_Type Trip4.7 Time_Type Trip4.10 Timepoint Timepoint4.4 Timetable_Header Route4.8 Track Transit Stop4.9 Transfer_Cluster Transfer Cluster4.8 Transit_Facility Transit Stop4.6 Transit_Path Pattern4.6 Transit_Path_Event Pattern4.6 Transit_Point_Event Pattern4.8 Transit_Stop Transit Stop4.7 Trip Trip4.7 Trip_Time Trip

Facility and Amenity Data Concept RequirementsSimilar to the Schedule and Service Type data concepts, the SDP includes requirements for passenger facilities (see [2, Section 4.8]). The passenger facility data concept is based on an extendable data model. Key definitions for the data concept are shown in Table 27. The parking facility description related to transit service may be found in Section9 Appendix C.

document.docx 64


Table 27: SDP Transit Passenger Facility Description (from [2])

SDP Data Name(Data Concept Name)

SDP Transit Passenger Facility Description

Amenity(Transit Facility)

Elements of a physical feature, a fixed location, or a transit facility. Example: the amenities of a public transportation stop may include the shelter, platform announcement panel, and benches. Note: an amenity may be described by one or more characteristics, or attributes, such as the year of construction or its current condition. [5, part 7d, p., 2]

Connection Segment [also ConnectionSeg](Transfer Cluster)

The directions between two stops within a Transfer Cluster. The directions may describe accessible and mobility-challenged instructions.

Passenger Access Component(Transit Facility)

The components used to aid travelers to traverse from one level to another or from one end of a facility to another.Examples include stairs, elevator, escalator, moving walkway. The component may be described by direction (up, down, or both), accessibility for people with disabilities or carts, and other characteristics.

Plant Component(Transit Facility)

A Plant Component is a physical part of a larger facility such as a boarding area, turnstile, fare vending machine, information booth, escalator, stairs, etc. The four specific types of plant components included in this model are Transit Stop or boarding area, Amenity, Access Component and Portal.

Status (Plant Component)

The state or condition of the Plant Component with respect to the dates of placement, activation, deactivation, etc.

Track(Transit Facility)

"A pair of parallel rails, and required ties and fastenings, over which trains move." [LIRR] Also known as Lane and Berth

Track Association(Transit Facility)

An association between a specific platform and track. A Platform may be associated with multiple Tracks, for example, platform "A" at Jamaica Station is flanked on both sides by track 1 and 2. Alternatively, a track may support multiple platforms, such as platforms A and B are served by Track 2. This entity distinguishes the combined relationship between one platform and an adjacent track.

Transfer Cluster (Gazetteer)

A place where transit customers may transfer from one service provision to another such as from one bus to another, or from one mode of travel to another. The Transfer Cluster may include related information on the connecting trips (see EventConnection) and directions between the connecting stops (ConnectionSeg).

Transit Facility(Transit Facility)

A building or center used by a transit vehicle or transit operator for the purpose of parking, storing, maintaining or providing services to transit customers.The SDP uses this entity to represent multiple transit stops wherein transfers may occur between routes, modes and/or operators. Although a transit facility in a general sense may also encompass a vehicle garage, maintenance yard, administration building or other facility type, within the context of the SDP, only

document.docx 65


facilities that serve the public need be included.

Vehicle Fleet Data Concept RequirementsVehicle Fleet information is used for capacity planning, that is, available bus and train seat and standing room capacity that drives fleet requirements. The current definition of SDP includes an element for type of vehicle (Public Transit Vehicle in Block – PTV in Block); the data concept, however, is not implemented in the SDP XML Schema beyond a reference to a code for vehicle type (vehType). Further, the specification does not include any information on rail vehicle capacity (consist, number of cars, seating and standing capacity by car). Since the planning needs9 only require information related to capacity, and not specific vehicle identification, the following requirements define “vehicle passenger fleet type” or vehicle type.

Vehicle Passenger Fleet Type DefinitionA vehicle passenger fleet type is a category of conveyance assigned to public transportation revenue service that carries public transportation patrons.

Vehicle Passenger Fleet Type RequirementsRequirements for the Vehicle Passenger Fleet Type are listed in Table 28.

Table 28: Vehicle Passenger Fleet Type Requirements

# Category Requirement1 Uniqueness and

identify A vehicle fleet type is referenced by a unique identifier. A vehicle fleet type has a name such as the name of the

manufacturer or series.2 Vehicle capacity

characteristics A vehicle type typically may be configured in various ways to

include different arrangement for seating, standing areas, wheel chair and special seating. The arrangement changes the number of benches / seats, standing areas, wheel chair restraints, and special seating areas in the vehicle.

The seating configuration in a vehicle type has total, seating, standing, and wheel chair passenger capacities.

Note: the vehicle capacity may or may not uniquely describe a vehicle type.

The vehicle capacity characteristics covers each passenger conveyance including bus, passenger rail car, light rail car, ferry, etc.

3 Rail Vehicle Capacity characteristics

The number of rail passenger cars in a consist. For trains, the consist (set of passenger cars) is an additional requirement. During peak periods subways may run a consist of six cars, while at other times only four cars are available to carry patrons. Note that sometimes, the platform length limits the size of a consist.

4 Revenue Assignment A vehicle type (or a specific vehicle of vehicle type) is typically assigned to scheduled work. For a bus, the scheduled work is typically

9 From the Planning Concept of Operations Addendum [1].

document.docx 66


called a Block; for a rail vehicle (light rail, heavy rail-subway, or commuter rail), the assignment is typically made at the Trip (or Train) level.

5 Depot A vehicle fleet type may be assigned to one or more depots (vehicle storage or maintenance garages).

Details of the Public Transit Vehicle Description and Data Model are documented in Appendix D: VehicleDescription Data Concept Description.

4.1.3 Service Supplied Summary Data Set RequirementsThe service supplied summary data set includes both selected information about trip frequency, headway, running times (derived from trip schedule information), and service capacity parameters. The summary data set includes data that is modeled by the extended SDP data model (including parking facility (Appendix C) and Vehicle Fleet Data Requirements (Section 4.1.2)) in a summary data set.

The Service Supplied data needs are:

Routes (by route direction), Trips, Route Segments (by stopping pattern) or Transit Facility (including stop)

o Modeo Average running time (scheduled)o Headways/frequencyo Service type (local, express, etc.)o Span of Serviceo Capacityo Transfer Opportunities (coordinated service)o Planned exceptions to scheduled service (due to detour or event)

Comparison of Scheduled Service and Services Supplied from different time periods (as defined by the Time Period Dimension)

o New serviceo Eliminated serviceo Expanded serviceo Changed service

The data sets include the raw data from an extended SDP document as submitted by a transit provider. For example, if a planner requests headway information with the following criteria:

o AM Peak period o A single route inbound (going into New York City) operated by a specific transit provider

then the summary data set (i.e., the planning data concept data set depicted in Figure 3) consists of each trip and the average difference in time from one trip departure time to another for the time period (depicted as the time dimension data set) of interest in the geographic area of interest as depicted as the spatial dimension data set.

This section describes the information that will be contained in each summary data set for each service supplied summary data concept.

document.docx 67


The summary data sets are defined by the needs listed above. The specific data sets that will be generated are listed in Table 29. These data sets are parsed by temporal and spatial dimensions described in Section 3.

document.docx 68


Table 29: Service Supplied Summary Data Set and Summary Data Concept Requirements

Planning Concept / SDP Data

Routes (by direction) Trips Route Segments (transit path)

Transit Facility (stops and transfer cluster)

Mode List mode by route Not applicable Transit path by definition is assigned a mode. List mode by transit path.

List modes that serve transit facility, stop or transfer cluster

Running Time Not applicable List raw trip information, sorted by pattern; calculate average scheduled running times from origin to destination.

List trips that traverse route segment and average scheduled running time from route segment origin to destination

Not applicable

Headway (service and effective) / Frequency

See Trips Service HeadwayList raw trip information for each route sorted by timeStart and pattern; calculate the average of the difference in time between one trip and the next; calculate the number of trips that are included in calculation (for Frequency).

Effective HeadwayList and order raw trip information for all the routes that traverse the route segment, and calculate service headway and then effective headway.

Effective HeadwayList and order trip information for all the routes that stop to board and alight passengers at that facility, and calculate service headway and then effective headway.

Service type See Trips List service type by raw trip information for each route sorted by pattern, e.g. local or express.

List service type by all trips for all the routes that traverse the route segment.

List service information by all trips for all routes that stop to board and alight passengers at that facility.

Span of service See Trips The timeBegin of the first trip to the timeEnd of the last trip in a Schedule Day.

The timeBegin of the first trip to enter the route segment, and the

The tripTimes of the first and last trips to provide service to the transit facility in a Schedule Day. Maximum number

document.docx 69





Maximum number of hours is 24.

timeEnd of the last trip to exit the route segment in a Schedule Day. Maximum number of hours is 24.

of hours is 24.

Capacity See Trips The total vehicle capacity (as defined by PTV_Type) for each Trip for a route (by direction and sorted by pattern).

The total vehicle capacity (as defined by PTV_Type) for trips for all routes that traverse the route segment.

The total vehicle capacity (as defined by PTV_Type) for trips for all routes that stop at the transit facility.The platform or pad capacity for transit stops.

Transfers Not applicable A list of the raw data that describes Event Connection elements for specified trips.

Not applicable A list of the raw data that describes Event Connection elements for specified transfers that occur at specified transit facilities (facility, stop, transfer cluster). This data also includes linear distance between transfers. [Note: the parking facility data concept supports linear distance and passenger access components between the parking and transit facility.]

Planned exceptions (temporary revisions to the schedule)

List of all the temporary revisions to an original schedule as submitted to the SDP. For each temporary revision, the activation and deactivation dates, the routes that were replaced with changes.OR

Not applicable Not applicable Not applicable

document.docx 70





List of all special schedules from the DayType or Schedule Calendar Profile (SCP).

document.docx 71


Definition of Planning ConceptsNote: the definitions use data concepts defined in the SDP data model. These definitions may be found in the Glossary in Appendix A-1. SDP data concepts are italicized.

Mode Definition“A transit service type category characterized by specific right-of-way, technological and operational features.” (from SDP [2, p., 43] and cited from NTCIP 1401:2000)

The element is described as an enumerated type that used National Transit Database [4, Glossary] categories for mode. They include the following:

AG -- Automated Guideway CC -- Cable Car CR -- Commuter Rail DR -- Demand Responsive FB -- Ferry Boat HR -- Heavy Rail or Subway IP -- Inclined Plane JT -- Jitney LR -- Light Rail MB -- Bus (motor bus) MO -- Monorail PB -- Publico TB -- Trolleybus AT -- Aerial Tramway VP -- Vanpool OR -- Other DM -- Dual Mode MM --Multimode PRT -- Personal rapid transit BRT -- Bus rapid transit WT -- water taxi TC -- taxi cab CO -- coach bus

In addition to the typical NTD mode types, the SDP element includes a designator for bus rapid transit (BRT)10. Guidance for transit providers in completing this field may be found in the SDP [2, Guidance Part 2, Section A-2.]

10 BRT may be defined by some organizations as a Mode and by others as a Service Type. For that reason, they are included in both the Mode and ServiceType code lists.

document.docx 72


Running Time (Scheduled) DefinitionThe duration (in seconds) needed for a public transportation vehicle in revenue service to travel between a known location (locationID) to another over the same path, for example, for one or more trips, between each trip’s locationBegin to locationEnd, or between one TripTime to another.

The equation (calculation) to derive average running time is as follows:

Equation 1: Average Running Time

average=1n∑i=1

n

t ( i )destination−t ( i )origin

Where “t” indicates the time in seconds at the starting and ending locations (origin and destination, respectively) and “n” indicates the number of trips included in the calculation.

Service Type DefinitionService type is a classification for the level of service provided by a trip. Typically, the service type is associated with the mode (i.e., coach versus motor bus) and speed and reliability of the service (express versus local).

A new field will be added to the Trip element to describe the serviceType (serviceType_cd). It will include the following enumeration categories11:

regular express circular radial feeder jitney limited Bus Rapid Transit (BRT)12

non-revenue

charter school special training maintenance No-service stand-by extra

Span of Service DefinitionSpan of service is the range of revenue service provided to transit customers. The span starts from the time the revenue service begin (Trip timeBegin) until the last trip of the day (Trip timeEnd). The maximum range is from [00:00 to 23:59].

Transfer Opportunity DefinitionA transfer opportunity is one where a transfer between trips or routes (by direction) is accessible and convenient.

11 These types are adpated from TCIP:2006, SCH-ServiceType {SCH-4}.12 BRT may describe a mode of service or service type. Furthermore, some organizations may categorize BRT as “express” service [serviceType].

document.docx 73


The SDP data that contribute to deriving information about transfer opportunities that are coordinated or recommended by a Data Provider (i.e., transit operator) are contained in the Event Connection element. The Event Connection element also references the Transfer Cluster and Connection Segment for additional information (both of those data concepts may be requested independently as described in Section 3.1, Transit Network). As described in the SDP requirements document,

The Event Connection is “the provision for a connection between two route/trips at a trip time event. Connection types include [protected, recommended, scheduled].”

The Transfer Cluster is “a collection of transit stops where transfer between stops is convenient and scheduled.” It may include information on the connection segment between stops within the cluster.

The Connection Segment “is a linear path allowing transit riders to move from one Transit Stop to another. The segment may be defined as a walking path, bike path, escalator or other modal connection. Attributes include distance, fromStop, toStop and connection instructions. Accessibility information in the form of obstacleTypes may optionally be provided for Connection Segments.”

Frequency Definition Frequency is defined in terms of number of vehicles per time period. For example, the bus frequency during the peak period traveling northbound on Main Street is 10 buses per hour.

Frequency may be calculated by counting the number of trips that traverse a pattern, route segment, corridor, or transit facility (stop) in a specified time period.

Headway DefinitionHeadway is defined as the time between trips along a route (by pattern) or corridor, or the time between trips that stop at a transit facility. The types of headway -- service and effective, are defined as follows:

Service Headway: Number of minutes between buses, trains or other mode on a particular route or line, e.g., B9 NYCT bus, LIRR Port Jefferson Line, or at a particular station. Represented as a number of minutes between transit vehicles on that route or at that station, in one direction, during a specific time of day, for a single transit route.

Equation 2: Average Service Headway

serviceheadway=1n∑i=1

n

t (i )current trip−t (i−1 )last trip

Where “t” indicates the time in seconds for the last (t-1) and current (t) times of successive trips (for a common location), “n” indicates the number of trips included in the calculation (constrained by the time period under consideration). Note: i=1 and i - 1=0 is the first trip.

document.docx 74


Effective Headway: Composite headway of all bus, rail or other mode service at a stop or in a corridor based on vehicle frequency, the number of vehicles per hour divided by 60 minutes. In other words, the effective headway is the number of minutes between transit vehicles when all headways are combined.

Equation 3: Effective Headway

effective headway=60/∑i=1

n

60/ SH (i)

Where “SH” refers to the service headway and “n” refers to the number of service headways that are included in the calculation of the effective headway.

For example, if there are two routes operating on a segment of roadway (or track) each with ten minute headways, the effective headway is five minutes.

Effective headway = 60 / (60/10 +60/10) = 5 minutes

For example, when calculating effective headway for the stop at E 116 Street and 3rd Avenue where service is provided by the Routes 98, 101, and 103 with service headways of 10, 7 and 5 minutes (respectively), then the effective headway would be:

Effective headway = 60 /[(60 minutes / 10 minute headway) + (60 minutes / 7 minute headway) + (60 minutes / 5 minute headway)] = 60 minutes / 26.6 buses hour

and

Effective headway = 60 minutes / 26.6 buses hour = 2.25 minutes

Capacity DefinitionCapacity can be defined as the total number of passengers a transit vehicle can carry by route stopping pattern over an hour. Capacity data concepts may also include the total capacity of a corridor, total capacity of a bus or train, seat capacity, standing capacity, and capacity miles.

Capacity by Time Period is the summation of the vehicle capacities for all the vehicles that traverse the geographic selection (e.g., route, corridor, and stop) during a specified time period. For example, if three buses travel in a route direction along a route during an hour period during AM Peak, then the vehicle capacity when 60 passenger buses are used is 180 passengers per hour during AM Peak.

Planned Exceptions to Scheduled Service (due to detour or event) DefinitionPlanned exceptions that are published as temporary schedules and extra service.

The content of the information is contained in the SDP document. It contains the activation period, schedule version and revision which is impacted, and all the service information pertaining the route that was changed (including mode, patterns, trips, and stop locations).

document.docx 75


4.1.4 Service Supplied Data Set DescriptionThis section contains the description of the data concepts that are included in the Service Supplied Data Sets as described by the requirements (Table 29) above. Table 30, which mirrors the data set requirements of Table 29, references the structure of each data set related to the planning concept and raw SDP data.

The data set description shall include the time and spatial dimensions that were used to select the data set coverage as described in Section 2.4 above.

Table 30: Data Description for Service Supply Data Sets


Routes (by direction)

Trips Route Segments (transit path)


Mode Data Set see Mode Data Set

See Mode Data Set

See Mode Data Set

Running Time Data Set See Pattern Running Time

See Corridor Running Time

Headway Data Set for service and effective headways, and frequency

See Service Headway

And Frequency

See Effective Headway

See Effective Headway

Service type Data Set See Service Type Data Set

See Service Type Data Set

See Service Type Data Set

Span of service Data Set See Span of Service Data

Set

See Span of Service Data

Set

See Span of Service Data Set

Capacity Data Set See Capacity Data Set

See Capacity Data Set

See Capacity Data Set

Transfer Service Data Set See Transfer Service Data

Set

See Transfer Service Data Set

Planned Exception Data Set See Planned Exception Data

Set

Mode Data Set DescriptionThe mode data set contains information on the mode of different routes that apply to the SDP domain elements (route, trip, corridor, or transit facility). The planning data set package contains the detailed data on each route and its mode (and agency if necessary), and the number of fields contained in the set. The Spatial Dimension data set contains the selection criteria (service area of an agency, corridor, polygon, or transit facility) to which this data set applies. For example, if the service area of an agency is

document.docx 76


selected, and the agency has ten bus routes and one ferry route, then eleven routes will be included in the data set. The structure for the data set is described in Figure 16.

Figure 16: Structure for Mode Data Set

The RouteModeList contains the detailed data of interest including the route identifier, agency to which the route belongs, and the route mode. When only one agency is designated, then agencyID does not need to be included. Mandatory elements, element names, and descriptions or references to the SDP descriptions are specified in Table 31.

Table 31: RouteModeList Description

Key Name / Role Name Description or ReferenceMandatory routeID Reference attribute table in Appendix A (Section 8.3.2)Mandatory mode Reference attribute table in Appendix A (Section 8.3.2)Optional agencyID Reference attribute table in Appendix A (Section 8.3.2)

In the example above, the Mode Data Set that results would be documented (in XML) as follows:

<ModeDataSet><count>11</count><routeModeList>

<entry><routeID>1</routeID><mode> MB</mode></entry><entry><routeID>2</routeID><mode> MB</mode></entry><entry><routeID>3</routeID><mode> MB</mode></entry><entry><routeID>4</routeID><mode> MB</mode></entry><entry><routeID>5</routeID><mode> MB</mode></entry><entry><routeID>6</routeID><mode> MB</mode></entry><entry><routeID>7</routeID><mode> MB</mode></entry><entry><routeID>8</routeID><mode> MB</mode></entry><entry><routeID>9</routeID><mode> MB</mode></entry>

document.docx 77

Mode Data Set

count

RouteModeListrouteIDmodeagencyID


<entry><routeID>10</routeID><mode> MB</mode></entry><entry><routeID>F1</routeID><mode>FB</mode></entry>

</routeModeList></ModeDataSet>

Running Time Data Set DescriptionAs shown in Figure 17, the running time data set is a hierarchical data set because a route contains one or more patterns, and a corridor may contain one or more route segments.

Figure 17: Structure for Running Time Data Set

The second tier of information requires that average running times be associated with a specific segment and the number of instances that compose the average. The general format for the second tier (whether a patternID or tranPathID) is the following:

Average Running Time – see Equation 1.

document.docx 78

Running Time Data Set

count

pathList

average Running Time

number

segmentID

first Location

next Location

path Running Time List

agencyID

routeID

routeDirection

tripID

firstTripTime

nextTripTime


Number (“n”) (as in Average Running Time Equation) Segment (patternID or tranPathID) First Location (origin) Next Location (destination) Path Running Time List (including agencyID, routeID, routeDirection, tripID, tripTime (first

location), tripTime (next location))

The data concepts are described in Table 32.

Pattern Running Time Data Set DescriptionThe Pattern running time is an average of the running time from timeStart to timeEnd for each trip of the same pattern for a given time period. The trips selected to calculate the running time must match the patternID. If a route is selected that includes more than one pattern (in a designated direction), the pathList will include all the route patterns in that direction. When this data set is associated with a pattern, then the segmentID references a patternID, and the agency for which the running time is associated is assumed.

Corridor Running Time Data Set DescriptionThe corridor running time is the average of every tranPathID that is associated with the corridor. Each triptimeList entry that matches the Transit Path (first and next locations) will be grouped into a unique pathList. When the data set is associated with a corridor and more than one transit agency may be assumed, then the segmentID and locationIDs (for first and next Locations) should use a regional reference (see Section 15 Appendix H).

document.docx 79


Table 32: Running Time Data Set Description

Key Name / Role Name Description or ReferencePattern Running Time Option Corridor Running Time Option Example

Mandatory count Number of patterns in the pathList Number of segments or transit paths in the pathList.

4

Mandatory pathList Includes all the patterns (grouped by route direction) as listed in the spatial dimension data set) – See Pattern Running Time Data Set Description

Includes all the Transit Paths as listed in the spatial dimension data set. – See Corridor Running Time Data Set Description

--- (4 sets of sample data shown as comma separate)

pathList DescriptionMandatory averageRunningTime The result of Equation 1. Same as Pattern 15.2, 7.0, 9.5, 12.5Mandatory number The “n” in Equation 1. Same as Pattern 3, 4. 4, 4Mandatory segmentID patternID tranPathID (from a regional reference) E/1.1, E/1.2, E/1.3Mandatory firstLocation Reference to origin in Pattern Reference to origin in TransitPath (if a

transit stop, then use a shared stop reference from the regional references)

T1222, T 1223, T1224, T1225

Mandatory nextLocation Reference to destination in Pattern Reference to destination in TransitPath (see note above)

T 1223, T1224, T1225, T1226

Mandatory pathRunningTimeList

See below See below ‘—includes inputs consistent with “number” above: 3, 4, 4 and 4.

pathRunningTimeList Description Example for Pattern E/1.1 (3 records)

Optional agencyID Reference data concept table in Appendix A

Same as Pattern 212, 212, 212

Mandatory routeID Reference data concept table in Appendix A

Same as Pattern E/1, E/1, E/1

Mandatory routeDirection Reference data concept table in Appendix A

Same as Pattern first, first, first

document.docx 80


Mandatory tripID Reference data concept table in Appendix A

Same as Pattern E/1_1_1, E/1_1_2, E/1_1_3

Mandatory firstTripTime For each Trip use timeBegin element. From the related tripTimeList (in Trip), the tripTime that matches the firstLocation (and nextLocation if first location is included more than once in the stopping pattern);

17220, 20700, 22800

Mandatory nextTripTime For each Trip use timeEnd element. From the related tripTimeList (in Trip), the tripTime that matches the nextLocation (and firstLocation if nextLocation is used more than once in the stopping pattern).

21420, 24720, 24300

document.docx 81


Headway (Service and Effective) / Frequency DescriptionThere are three versions of the headway data set, one for service headways, one for effective headways, and the last for frequency. They are calculated as described in Section 4.1.3.

Service Headway Data SetThe service headway data set applies Equation 2 to generate average Service Headway in a given direction during a given time period. The data set shall include the service headway for a specified route, in a designated direction. The data can constrain the measure to a specific pattern, or use a TripTime location that is common to all patterns that belong to the route (in that route direction). The number of trips and each trip that is included in the service headway calculation are also included in the summary data set. The data set is illustrated in Figure 18 and the data concepts are listed in Table 33.

Figure 18: Structure for Service Headway Data Set

document.docx 82

Service Headway

avg Service Headway [min]

routeID

routeDirection

patternID (opt)

common Trip Time Location

numberTrips

TripList Trip with tripTimeList


Table 33: Service Headway Data Set Description

Key Name / Role Name Description or Reference Example: Sample Data*Mandatory avgServiceHeadway Number of minutes between buses,

trains or other mode on a particular route in a specified direction.

6.48

Mandatory routeID Reference attribute table in Appendix A (Section 8.3.2)

M01

Mandatory routeDirection Reference attribute table in Appendix A (Section 8.3.2)

first

Optional patternID Reference attribute table in Appendix A (Section 8.3.2)

---

Mandatory commonTripTimeLocation

Reference locationID attribute table in Appendix A (Section 8.3.2)

26fd

Mandatory numberTrips An integer referring to the number of records contained in the TripList .

30

Mandatory TripList Reference to TripTime data concept table in Appendix A (Section 8.3.1)

M01_1_354 to M01_1_542

* M1 Weekday Schedule Effective June 27, 2010, trips starting from 6:42 to 9:02 [included limited service]. (See Appendix H: Sample Data for Service Supplied Examples).

Effective Headway Data SetThe effective headway data set applies Equation 3 to generate effective headway for multiple routes along a corridor or at a specific transit facility. The data set shall include the effective headway for the corridor or transit facility (the Transit Network and Time Period data set identify and constrain the geography and time period(s)); the number of calculated service headways that are included in the measure; and the actual service headway data sets. The data set is illustrated in Figure 19 and described in Table 34.

document.docx 83


Figure 19: Structure for Effective Headway Data Set

Table 34: Effective Headway Data Set Description

Key Name / Role Name Description or ReferenceMandatory avgServiceHeadway Number of minutes between buses, trains or other mode on a

particular route in a specified direction.Mandatory numberServiceHdwys An integer referring to the number of records contained in the

ServiceHeadwayList .Mandatory serviceHeadwayList Reference to ServiceHeadway Data Set (see section on Service

Headway Data Set Description)

Frequency Data Set DescriptionThe Frequency Data Set includes the frequency, calculated as the vehicle (or trips) per hour and the trips that were used to calculate the frequency measurement. The Frequency Data Set is illustrated in Figure 20 and described in Table 35.

document.docx 84

effective Headway

effective Headway [min]

number Service Headway Records

service Headway List [1..n]

[see Service Headway

description]


Figure 20: Structure for Frequency Data Set

Table 35: Frequency Data Set Description

Key Name / Role Name Description or Reference Example: sample data*Mandatory vehPerTimePeriod Number of vehicle per time

period.12

Mandatory tripList Reference to Trip Data Concept (see Section 8.3.1)

include 12 sets of Trip elements for M01_1_422 to M01_1_476

Mandatory Trip Reference to Trip Data Concept (see Section 8.3.1)

*See Appendix H: Sample Data for Service Supplied Examples. Time period from 7:00 am to 8:00 am weekdays on the M01.

Service Type Data Set DescriptionThe service type data set, similar to the mode data set description, associates a service type to each trip that traverse a corridor or stops at a Transit Facility for each route (by route direction) specified. The Service Type data set structure is illustrated in Figure 21 and described in Table 36.

document.docx 85

Frequency Data Set

veh Per TimePeriod

tripList Trip (without tripTimeList)


Figure 21: Structure for Service Type Data Set

Count is similar to the mode field. In addition, one or more TripList elements shall be included in the Service Type data set. The TripList contains the detailed data including the tripID, routeID, route direction, agency to which the route belongs, and the service type. Mandatory elements, element names and descriptions or references to the SDP descriptions are specified in Table 36.

Table 36: Service Type Concept Description in Trip List

Key Name / Role Name

Description or Reference Example: sample data*

Mandatory tripID Reference attribute table in Appendix A (Section 8.3.2)

M01_1_452


M01


first

Optional agencyID Reference attribute table in Appendix A (Section 8.3.2)

101

Mandatory serviceType Service type is a classification for the level of service provided by a trip. Typically, the service type is associated with the mode (i.e., bus versus rail) and speed and reliability of the service (express versus local).

limited

*See Appendix H: Sample Data for Service Supplied Examples.

document.docx 86

Service Type Data Set

count

tripList

tripID

routeID

routeDirection

agencyID (optional)

servicetype


Span of Service DescriptionThe span of service description includes the duration of service for an agency, along a corridor, on a particular route, or at a transit facility. The information is computed based on the starting time of the first trip to the ending time of the last trip, or from the first trip that arrives (or leaves) the facility to the last trip to leaves (or arrives) at the facility. The span of service data set structure is illustrated in Figure 22 and described in Table 37.

Figure 22: Structure for Span of Service Data Set

document.docx 87

Span of Service Data Set

serviceSpan

firstTrip

tripID

routeID

routeDirection

timeType [arrival/departure]

tripTime

(optional) agencyID

lastTrip See above


Table 37: Service Span Data Concept Description

Key Name / Role Name

Description or Reference Example: sample data

Mandatory serviceSpan Within a twenty four hour clock, the number of minutes in a calendar day in which transit service is provided. Maximum possible minutes is: 1440.

1147

Mandatory firstTrip or lastTrip

The first trip of the day or the last trip of the day

2 records: [first trip, last trip]


123, 321


3262, 6543


first, second

Mandatory tripType Reference attribute table in Appendix A (Section 8.3.2) -- valid enumerations include beginTrip, endTrip, arrival, departure, passing

regular, regular

Mandatory tripTime Reference attribute table in Appendix A (Section 8.3.2) – departure for first stop for first trip and arrival at last stop for last trip (in units are in seconds past midnight.

24120, 92940

Optional agencyID Reference attribute table in Appendix A (Section 8.3.2)

310, 310

Capacity Data Set DescriptionAs a measure of total number of passengers per hour by pattern, corridor, or through a transit passenger facility, capacity is the sum of vehicle passenger capacity assigned to each trip that traverses the geographic dimension over the time period (e.g., 1 hour). The capacity data set shall include the sum of each trip’s PTV_Type capacity measures: totalCapacity, seatingCapacity, standingCapacity and wcCapacity (as described in Table 69); for trains, the capacity data set shall include the summation of each car’s PTV_Type capacity measures times the number of cars in the consist. The Capacity Data Set structure is illustrated in Figure 23 and described in Table 38.

Table 38: Capacity Data Set Description

Key Name / Role Name Description or Reference Example: sample data*Mandatory sumTotalCapacity The Capacity measure for total

passenger capacity per hour114

Optional sumSeatingCapacity The Capacity measure for seating 114

document.docx 88


capacity per hourOptional sumStandingCapacity The Capacity measure for standing

capacity per hour0

Optional sumWcCapacity The Capacity measure for passengers in wheel chairs per hour

4

Mandatory tripCount Number of trips included in the TripList (see below)

2

Mandatory TripList See description of element below. see below (trips separated by commas)


TAPPAN ZEEXP_E/1_1_11, TAPPAN ZEEXP_E/1_1_14


TAPPAN ZEEXP, TAPPAN ZEEXP

Mandatory patternID Reference attribute table in Appendix A (Section 8.3.2)

TAPPAN ZEEXP_E/1, TAPPAN ZEEXP_E/1

Mandatory totalCapacity Reference to attribute in Table 69. 57, 57Optional seatingCapacity Reference to attribute in Table 69. 57, 57Optional standingCapacity Reference to attribute in Table 69. 0, 0Optional wcCapacity Reference to attribute in Table 69. 2, 2Optional carCount Reference to attribute in Table 72. ---Optional agencyID Reference attribute table in

Appendix A (Section 8.3.2)211

*The example is for the Tappan ZEExpress (TZE) between the hours of 7 to 8 am for two trips with the same patternID (begin and end stops). Both trips use the MCI Coach D4500 which has a lift and two wheelchair tie-downs that are stored behind a slide back seat.

An example for a rail consist is included in Appendix D: Vehicle Description Data Concept Description.

document.docx 89


Figure 23: Structure for the Capacity Data Set

document.docx 90

Capacity Data Set

sumTotalCapacity

sumSeatingCapacity

sumStandingCapacity

sumWcCapacity

tripCount

tripList

tripID

routeID

patternID

(optional) agencyID

(optional) carCount

totalCapacity

seatingCapacity

standingCapacity

wcCapacity


Transfers Data Set DescriptionThe transfer data set contains information on coordination between trips within an agency (e.g., connection protection, recommended transfers) and between two agencies. The SDP includes two key structures that support the reporting of transfer activities. The first is the TransferCluster data concept; it describes passenger facilities that are recommended for convenient transfer between services (routes). The actual path and distance from one stop to another may be described through the ConnectionSegment data concept. The other concept is the EventConnection; it describes the two trips that intersect at a stop, facility or transfer cluster where a transfer between services are coordinated, guaranteed or recommended. Two summary data descriptions are included to meet the requirements of the Transfer Data Set. They include trip level transfers (event connection) or physical infrastructure transfers (transit facility).

Note that not all transfers that are possible are included in this data. The data only contains transfers that are explicitly recommended by the transit agencies. A trip planner identifies transfer opportunities through a proximity algorithm – by identifying when two stops are within a close distance of each other.

Trip Transfer SetThe trip transfer data set includes the SDP data related to event connections within the selected temporal or spatial dimensions. It includes the EventConnection data and all related data (trip, stop, transfer cluster, locations). The Trip Transfer Data Set is depicted in Figure 24 and described in Table 39.

Figure 24: Structure of Trip Transfer Data Set

document.docx 91

Trip Transfer Data Set

tripTransferCount

EventConnectionList

AgencyTripData (1..n) AgencyTripList

agencyID

TripList

RouteList (opt)

LocationList (opt)

TransferClusterList


Table 39: Trip Transfer Data Set Description

Key Name DescriptionM tripTransferCount The number of event connections included in the data set.M eventConnectionList Refer to SDP EventConnection for multi-agency data concept

(2, Section 4.7). Reference Event Connection data concept in Appendix A (Section 8.3)

M AgencyTripData See definition belowO TransferClusterList Refer to SDP TransferCluster for multi-agency data concept (2,

Section 4.9). Reference Transfer Cluster data concept in Appendix A (Section 8.3)

AgencyTripData for each AgencyTripListPK agencyID Refer to SDP agencyID field description (2, Section 4.2).

Reference attribute in Appendix A (Section 8.3)M tripList A list of all trips contained in the event connection list. Each

Trip instance is described by the SDP Trip data concept (2, Section 4.7). Reference Trip data concept in Appendix A (Section 8.3)

O routeList A list of all routes that are referenced in the trip or event connection records. Route is is described by the SDP Location data concept (2, Section 4.3). Reference Route data concept in Appendix A (Section 8.3)

O locationList A list of all the locations that are referenced in the trip or event connection records. Location is described by the SDP Location data concept (2, Section 4.5). Reference Location data concept in Appendix A (Section 8.3)

In the case of Metro-North Railroad, they include several Event Connections associated with guaranteed transfers and specific locations. In the example below, the Event Connections relate to the following Trip Transfer pairs:

Event Connection from Trip to Trip Time between trains

at Stamford [locationID = 124] on the New Haven Line [routeID = 3]routeID, tripID, trip time 3, 6503, 21180 3, 6303, 21780 10 min

=(21780-21180)/60 srouteID, tripID, trip time 3, 1509, 21900 3, 1309, 22620 12 min = (22620-

21900)/60

Transit Facility Transfer SetThe transfer facility transfer set only includes the physical infrastructure for transfers between stops. The structure information related to the set of SDP Transfer Cluster records that are selected through the spatial and temporal dimensions. The data set includes the number of TransferCluster records, the description of TransferClusters and references to the agency or integrated location information

document.docx 92


referenced by the TransferCluster records. The TSIP also includes a master list of regional transit facilities. This set of locations is referred to as the Master Location List. The Transit Facility Transfer Data Set is depicted in Figure 25 and described in Table 40.

Table 40: Transit Facility Transfer Data Set Description

Key Name DescriptionM facTransferCount The number of Transfer Cluster records included in the data setM transferClusterList Refer to SDP TransferCluster for multi-agency data concept. Reference

Transfer Cluster data concept in Appendix A (Section 8.3)M MasterLocationList A list that contains location information that describes multi-agency

transit passenger facilities. Each record uses the SDP Location and Transit Facility data concepts to describe the location and facility characteristics. See [2, Appendix 2 – Shared Transit Facility List] for master list of shared facilities.

M AgencyFacData The relevant location and facility information is provided for each agency referenced in the Transfer Cluster records.

AgencyFacData – each agencyFacList containsPK agencyID Refer to SDP agencyID field description. Reference attribute in

Appendix A (Section 8.3)M locationList A list of reference locations. Each record is described by the SDP

Location data concept. Reference Location data concept in Appendix A (Section 8.3)

O facList A list of referenced Transit Facilties. Each record is described by the SDP TransitFacility data concept. Reference Facility data concept in Appendix A (Section 8.3)

document.docx 93


Figure 25: Structure for the Transit Facility Transfer Data Set

Planned Exceptions Data Set DescriptionThe planned exception data set lists revisions to an original schedule version that falls within the selected time period for a single agency. The SDP contains a record of each schedule version and related revisions. The revision might be a permanent or temporary version; it may relate to the entire schedule or to one or more routes within the schedule. The version may last for a single day, part of a day, several days, or through the deactivation date of the schedule version. For example, a snow schedule may be posted the night before a snow storm is expected. An event schedule may be developed and posted for a special event that is planned at a park or other venue.

The exceptions data set includes revisions to an original schedule. It uses the SDP ScheduleRevision and RouteDepotVersion data concepts. The Planned Exceptions Data Set is depicted in Figure 26 and described in Table 41. Examples of the implementation are included in the examples section below.

document.docx 94

Transit Facility Transfer Data Set

facTransferCount

TransferClusterList

MasterLocationList

AgencyFacData agencyFacList

agencyID

locationList

facList


Figure 26: Structure for the Planned Exceptions Data Set

Table 41: Planned Exceptions Data Set Description

Key Name DescriptionM scheduleCount The number of schedule versions included in the data set (that fall

within the time period data set).M scheduleList A list of all the schedule versions and its related exceptions that fall

within the selected time period.ExceptionList

M scheduleVersionID Refer to SDP scheduleVersionID field description. The scheduleVersionID references a specific SDP document. Reference Schedule Version data concept in Appendix A (Section 8.3)

M activationDate The date and time the schedule becomes active. The description of activationDate files is described in Appendix A (Section 8.3).

M deactivationDate The date and time the schedule is no longer valid. The description of deactivationDate files is described in Appendix A (Section 8.3).

M ScheduleRevision Refer to SDP ScheduleRevision data concept description in (2, 4.11). The scheduleVersionID and revisionNumber references a specific SDP document. ScheduleRevision includes the activation and deactivation dates for the revision, the schedule type (permanent, cancelled, temporary and permanent revision), history, and specific routes affected (if applicable). Reference Schedule Revision data concept in Appendix A (Section 8.3)

document.docx 95

Planned Exceptions Data Set

scheduleCount

scheduleList

scheduleVersionID

activationDate

deactivationDate

ExceptionList ScheduleRevision


Examples of the Planned Exception Data SetNote that the Planned Exceptions Data Set result will be based on Time Period and agency selection (the spatial dimension is not relevant to this data set). Schedule versions will be listed for service that starts before or ends after the selected time period. If the time period is designated for January through March of 2010, and Transit Agency #1 issues their Winter schedule (e.g., 110) from December 24, 2009 through April 21, 2010, then the list of exceptions will be associated to their schedule version 110.

For Transit Agency #2, with the following schedule versions:

Fall2009 – Sept 9, 2009 through January 4, 2010 Winter2010 -- January 5, 2010 through March 15, 2010 Spring2010 – March 16 through June 24, 2010

The exceptions for each schedule version will be shown relative to the schedule version related to the original.

document.docx 96


4.2 Service Consumed Data Concept and Set RequirementsThe service consumed requirements covers ridership levels for service provided to transit passengers. Although the parameters included in this document deal with passenger boardings and alightings at stops, and passenger loads between stops (e.g., route segments) and for each trip, the set of requirements could be expanded to include ridership demographics, (i.e., the types of riders patronizing transit), transit patrons passing through gated facilities (i.e., parking and stations), and more. This section describes the PDP definitions of the Service Consumed category, as well as related descriptions documented by policy publications and downstream applications.

4.2.1 Service Consumed DefinitionsService Consumed is the amount of services that are used by transit passengers related to their use of transit services and facilities.

Service Consumed data concepts include information about boardings and alightings at transit stops and the passenger loads related to trips and route segments that compose trips. In addition, there is a data concept related to “peak load,” which describes the route segment wherein the maximum quantity of passengers is carried by a transit vehicle during a trip or over multiple trips.

BoardingsThe quantity of passengers entering a transit vehicle in revenue service. Also called “ons” or “pickups.”

AlightingsThe quantity of passengers exiting a transit vehicle in revenue service. Also called “offs” or “departed.”

Passenger LoadThe quantity of transit patrons carried at a given time by a specified means such as a transit vehicle in revenue service.

National Transit Database DefinitionsAccording to the NTD, “service consumed is “[t]he amount of service actually used by passengers and which is measured by unlinked passenger trips and passenger miles.” [4, S-10]

Table 42: Service Consumed Related NTD Performance Measures

Performance Measure NTD Definition [4, NTD Glossary]Passenger Miles Traveled (PMT) The cumulative sum of the distances ridden by each passenger. Unlinked Passenger Trips (UPT) The number of passengers who board public transportation vehicles.

Passengers are counted each time they board vehicles no matter how many vehicles they use to travel from their origin to their destination.

Average Trip Length The average distance ridden for an unlinked passenger trip (UPT) by time period (weekday, Saturday, Sunday) computed as passenger miles (PM) divided by unlinked passenger trips (UPT).

document.docx 97


NYMTC Best Practices Model Service Consumed ParametersThe major service consumed measures needed by the NYMTC Best Practices Model (BPM) is defined by “capacity,” that is: “the average hourly capacity (persons/hour) for each pattern” [9, p., 15]. There are five capacity measures defined by the BPM. These are described in Table 43.

Table 43: NYMTC BPM Service Consumed Measures

Measure DescriptionAM Capacity AM Peak Period Capacity (persons per hour)Mid Capacity Midday Period Capacity (persons per hour)PM Capacity PM Peak Period Capacity (persons per hour)Eve Capacity Evening Period Capacity (persons per hour)Night Capacity Night Period Capacity (persons per hour)

4.2.2 Service Consumed Data Concept RequirementsThe service consumed data includes operational data for passenger counts (boarding/alighting) at each stop, loads by route segment and by trip as reported by each transit provider. Summary data sets are composed of these data consumption statistics and the requested time periods and spatial dimensions. The summary data set requirements are described in Section 4.2.3.

The requirements for the passenger count data concept are described in Table 44.

Table 44: Passenger Count Requirements

# Name Description1 Association to Stop Boardings and alightings are actions of passengers getting on or off a transit

vehicle in revenue service and a stop along the service (i.e., trip, part of a trip – route segment, or block).

Boardings/alightings are associated with stops Stops are associated with Patterns (and transit paths) and Trips (Bus) Trips are associated with Blocks

2 By door Passengers board and alight a passenger vehicle by door. In addition, different functions may be associated with a door to capture access needs, e.g., operation of wheelchair ramp or lift.

3 By accessibility requirement

Passenger ridership (boarding, alighting, loads) may be classified by different access needs, for example, passengers using wheelchair restraints by route segment(s) or trip, or boardings / alightings at stops using wheelchair lift or ramp.This information may be collected using an automated sensor (e.g., activation of lift or ramp) or manual procedures (e.g., operator or train crew noting use of lift, ramp or bridge).

4 Load, Trip Load A load is the quantity of passengers on board a transit vehicle as it travels along revenue service over a transit network segment (e.g., trip, route segment, or block length).

A trip load is typically composed of the cumulative number of passengers

document.docx 98


boarding a transit vehicle during a trip. A load for each route segment is typically calculated by the difference

between the cumulative number of passengers boarding and the cumulative number of passenger alighting the vehicle as it leaves a stop.

5 Scaling Factor and its relationship to counting technology testing

Current technology for counting passengers is inexact. Human, machine and other errors enter into the raw counting measures. Reporting data may be based on raw counts collected by automated or human collection procedures, or it may be corrected for bias and error. Different transit operators apply different types of correction procedures or criteria to accepting their automated technologies. They use different acceptance testing and periodic screening tests to measure its accuracy. Sometimes a scaling factor may be associated with correcting the load (cumulative ons) due to the counting technology. To this end, the scaling factor may be derived based on the technology and screening tests.

6 Load Constraints A load must be zero or greater. A load cannot be negative.7 Through Load – for

Loops and Interlining

Route configurations that do not require all passengers to alight the vehicle at a trip terminus, such as a loop or interlining service should count the continuing passengers as a “through load.”

In addition, for trips where only a few route segments are selected, the load prior to each stop’s boardings and alightings must be included to calculate the current load information.

See reference [10, pp., 54-62] for more on “Passenger Count Processing and Accuracy.”

8 Peak Load The peak load is the greatest number of passengers who are carried on a transit vehicle trip from the Trip’s locationBegin to locationEnd (elements refers to the SDP Trip data concept description). The peak load is typically associated with a part of the Trip (one or more route segments).

Passenger Count Data Concept DescriptionAs described in Table 44, passenger counts are associated with either a stop (identified as an event in the SDP TripTime element), with a route segment of a trip, a trip, (or a block for buses). The model then for each of these is logically related to schedule version, route, and trip (by trip time locationID). Table 45 describes the elements that should be included in a data concept to describe passenger count information.

Table 45: Description of Passenger Count Data Concept (Passenger Count List)

Key Name DescriptionPK date The date and time on which the information was collected.PK tripID Reference to element of SDP Trip in data concept table of Appendix APK routeID Reference to element of SDP Trip in data concept table of Appendix APK dayType Reference to element of SDP Trip in data concept table of Appendix AFK, O scheduleVersionID (optional) Reference SDP Document data concept table in Appendix AM countList For each trip time in the trip, the boardings/alightingsO scaleFactor A scale factor that the transit agency used to correct the count.

document.docx 99


O metadata A URL or link to a file that contains information about the collection procedures. The file is described in Section 6.See countList (6th row from the top – above)

PK tripTime Reference to SDP TripTimeList of Trip in data concept table of Appendix APK locationID Reference to SDP TripTime structure in data concept table of Appendix AM onCount Number of passengers boarding transit vehicle at this stop [non-negative

integer]M offCount Number of passengers alighting transit vehicle at this stop

[non-negative integer]O thruCount Number of passengers left on the vehicle from the previous travel. This

may also be defined as the load from the previous route segment.[non-negative integer]

O wcOnCount Number of passengers boarding who are using mobility device. [non-negative integer]

O wcOffCount Number of passengers alighting who are using mobility device. [non-negative integer]

O wcThruCount Number of passengers using mobility devices who are left on the vehicle from the previous travel. This may also be defined as the load from the previous route segment.[non-negative integer]

M cumulativeOn* Total number of passengers who boarded the transit vehicle since the trip started (when the doors are closed, as the vehicle leaves the stop). [non-negative integer]

O cumulativeOff* Total number of passengers who alighted the transit vehicle since the trip started (when the doors are closed, as the vehicle leaves the stop). [non-negative integer]

* Note: a simple load may be calculated for a route segment (between the stop just left and the next stop) by the difference between the cumulative Ons and Offs.

Where key codes are identified as follows:

PK indicates primary key and mandatoryFK indicates foreign key and optional (unless designated as M – mandatory)M indicates MandatoryO indicates Optional

Example of Sample Data for Passenger Count Data ConceptThe sample data in Table 46 shows a typical entry for the Passenger Count data set. This data set shows a single trip information for three consecutive stops where passengers boarded and alighted from a transit vehicle in revenue service. The data is manufactured but is typical of service during a weekday at high frequency stops.

Table 46: Example of Sample Data for Passenger Count List

Key Name Sample DataPK date 20100825

document.docx 100


PK tripID R01_1_346PK routeID R01PK dayType weekdayFK, O

scheduleVersionID

Summer 2010

M countList (see below)O scaleFactor ---O metadata ---

countListcountList (1) countList (2) countList (3) countList (4)

PK tripTime 27000 28800 30600 32400PK locationID 40001 40002 40003 40004M onCount 22 13 27 0M offCount 0 5 23 34O thruCount 0 17 7 0O wcOnCount 0 1 0 0O wcOffCount 0 0 1 0O wcThruCount 0 0 0 0M cumulativeOn 22 35 52 62O cumulativeOff 0 5 28 62[note: wheelchair is also considered an onCount and is counted twice, as such, the cumulativeOn and Off are calculated only from the on and offCounts.]

4.2.3 Service Consumed Data Set RequirementsThe structure that is inserted in the PDP Planning Data Set structure for the service consumed data set are composed of the raw service consumed data concepts and key composite information. The time period and spatial dimensions of each data is selected by specifying the temporal and spatial dimensions (as describing in Section 3). The data sets specified address the following data needs:

General ridership: passenger loads, boardings, and alightings data

o Trips by load

o Ridership at each stop (including all trips and routes associated with the stop)

o Ridership (boardings and alightings) at each stop belonging exclusively to a single route or set of trips

Each passenger count data concept describes a trip or part of a trip. To generate a data set that meets the request for a larger coverage based on the spatial data set selections (e.g., load for pattern or corridor by day type for a time period of a month), the data set must document the dates and trips that relate to the passenger count data.

The three needs may be defined by two different data sets:

Average Load Data Set

document.docx 101


Average Ridership Data Set

The average load data set accommodates loads by trip or transit network segment, such as a pattern or corridor. The average ridership data set describes the passenger counts at a specific location or set of locations.

Average Load Data Set DescriptionThe average load data set is composed of the calculation of average load for the segment of interest, a list of all the passenger count data concepts that relate to the coverage and time periods, and the number of values [n] that contribute to the average load calculation, as described in Equation 4.

Equation 4: Average Passenger Load Calculation for Multiple Trips

average load=1 /n∑i=1

n

cumulativeboardings [ i ]

Where average load for a trip is the cumulative boardings at the trip’s locationEnd for each trip, and n is the number of trips included in the selection.

Based on the time period selected, the first trip (when i=1) occurs at the start of the period, and the last trip (i=n) occurs at the end of the time period (as specified in the temporal data set).

The equation can also support calculation of average load in a corridor or route segment where the terminal points are the same or equivalent by calculating the average of the difference between the cumulative boardings and alightings for the segment for each trip that traverses the segment (see Equation 5).

Equation 5: Average Passenger Load Calculation for Multiple Route Segments (in a Corridor)

average load=1n∑i=1

n

cumulativeboardings [ i ]−cumulat ive alightings [i ]

Neither of the equations take into consideration the thruCount (as identified in the Passenger Count Data Concept, Table 45). The load information is just a snapshot of passenger load, and should be subject to rigorous review before use in a planning tool or study.

The average load based on the data in the Table 45 is

Average Load = 1/3 (22+30+24) = 25

The structure for the average load data set is depicted in Figure 27 and described in Table 47.

document.docx 102


Table 47: Average Load Data Set Description

Key Name Description Example from sample dataM pcCount The quantity of entries in the passenger

count list.3

M avgLoad The average load calculation as described in Equation 4 (for trip load calculation) or Equation 5 (for corridor, pattern or route segment level load calculations).

25

M passengerCountList A list of passenger count elements (see Section 4.2.2).

see Table 46 for PassengerCountList data

Figure 27: Structure for Average Load Data Set

Average Ridership Data Set (by Stop or Station) DescriptionThe average ridership describes the number of boardings and/or alightings for a given location. The data set contains the quantity of records used to calculate the average boardings, alightings, wheelchair boards, and/or wheelchair alightings for a given station or stop. Equation 6 shows the algorithm for calculating the average ridership parameter. The data set structure is depicted in Figure 28 and described in Table 48.

Equation 6: Average Boarding Calculation at a Transit Facility

average boardings=1/n∑i=1

n

onCount [ i ]

document.docx 103

Average Load Data Set

pcCount

avgLoad

passengerCountList passengerCount


Where n is the number of boardings for each trip time included in the selection.

Algorithms for average alightings, wcBoardings, and wcAlightings are similarly calculated by substituting offCount, wcOnCount and wcOffCount for onCount.

Table 48: Average Ridership Data Set Description

Key Name DescriptionM pcCount The quantity of entries in the passenger count list.M locationID Reference to element of SDP Location in data concept table of

Appendix A.M publicLocationDescription Reference to element of SDP Trip in data concept table of Appendix

A.M avgBoardings The average boarding calculation as described in Equation 6 using

the passenger count onCount values.M avgAlightings The average alighting calculation as described in Equation 6 using

the passenger count offCount values.O avgWCBoardings The average wheel chair boarding calculation as described in

Equation 6 using the passenger count wcOnCount values.O avgWCAlightings The average wheel chair alighting calculation as described in

Equation 6 using the passenger count wcOffCount values.M passengerCountList A list of passenger count elements as described in Section 4.2.2.

Only the trip time that is relevant to the location is included in the data set.

A sample data set that shows how the Average Ridership data set concept is populated may be composed of data from all the Monday trips between 7:00 and 8:00 am over the course of the month of August. For the sake of the example, we are looking at average alightings from a feeder service that transfers to a commuter rail service. The example, as shown in Table 49, includes the following assumptions about the data:

pcCount is 15o Five (5) Mondays in August 2010 o Three (3) trips (every 20 minutes) in the “first” route direction

locationID is the multimodal stop (bus and rail station) publicLocationDescription = “Transfer Rail Station”

Table 49: Example data for Average Ridership Data

Date Trip 1 Alightings[arrive at 7:08 am]

Trip 2 Alightings[arrive at 7:28]

Trip 3 Alightings [arrive at 7:52]

2 43 60 659 43 55 63

document.docx 104


16 42 54 6423 37 51 5430 34 43 47

avgAlightings 50 = 1/15 ( 755 )

Figure 28: Structure for Average Ridership Data Set

document.docx 105

Average RidershipData Set

pcCount

locationID

publicLocation Description

avgBoardings

avgAlightings

avgWCBoardings

avgWCAlightings

passengerCountList passengerCount


4.3 Accessibility Data Concept and Data Set RequirementsThere are three categories of impairment that need to be accommodated by transit accessibility, as defined by the Americans with Disabilities Act:

Mobility Visual Auditory

This section discusses the data requirements related to these three areas. The Planning Concept of Operations [1] identified general accessibility information needs; information included (1) whether a vehicle serving a route was accessible, (2) whether a transit stop or facility was accessible, and (3) the time it takes to traverse between parking and the transit stop for someone with mobility challenges. These needs are mostly met by the existing SDP data concepts; rather the needs require that the criteria for selecting transportation network and services embody attributes related to accessibility and mobility.

4.3.1 Accessibility DefinitionsMost definitions for “accessible” services derive from federal specifications to meet the Americans with Disabilities Act (ADA) or Architectural Barriers Act (ABA). The definitions in Table 50 are extracted from the guidelines and specifications published to ensure compliance with those two laws. Where available, definitions from the Schedule Data Profile Functional Requirements Document [2] are used.

Table 50: Terms and Definitions

Term Definition Source DefinitionAccessibility A continuous and unobstructed way of travel from one

point to another.Accessibility to Transit Stops

Accessibility to transit stops represents service coverage and is measured by how far (in distance or in time) a customer must walk to reach the nearest transit stop or station.

There are other aspects to pedestrian access that can also be measured - they include traffic volumes, pedestrian facility type, separation between pedestrians and traffic, etc. Similarly, bicycle access can be measured as well.

Americans with Disabilities Act (ADA)

The Americans with Disabilities Act of 1990 is legislation passed to prohibit discrimination against and ensure equal opportunity and access for persons with disabilities.

ADA Accessibility ADA accessibility issues include conditions of sidewalks and grades, working elevators escalators, rumble strips in appropriate locations, signage in Braille, etc.

ADA Accessible Public transportation passenger facilities, which provide Refer to 49 CFR Part

document.docx 106


Stations ready access, and do not have physical barriers that prohibit and / or restrict access by individuals with disabilities, including individuals who use wheelchairs.

37, Appendix. Reporting manual reference: A-10

ADA Accessible Vehicles with Lifts

Public transportation revenue vehicles, which do not restrict access, are usable, and provide allocated space and / or priority seating for individuals who use wheelchairs, and which are accessible using lifts.

Refer to 49 CFR Part 38. Reporting manual reference: A-30, RU-20

ADA Accessible Vehicles with Ramps/Low Floor

Public transportation revenue vehicles, which do not restrict access, are usable, and provide allocated space and / or priority seating for individuals who use wheelchairs, and which are accessible using ramps.

Refer to 49 CFR Part 38. Reporting manual reference: A-30, RU-20

Common Wheelchair

Those that do not exceed 30 inches in width by 48 inches in length measured 2 inches above the ground and not weighing more than 600 pounds when occupied.

(ADA 49 C.F.R. § 37.3). Common wheelchairs can include scooters.

Key Station Key stations include those with the most traffic, transfer stations, major interchange points with other transportation modes, most end stations, and stations serving major activity centers. A key station is one designated as such by the commuter authority or light/rapid rail operator

ADA 49 C.F.R. § 37.51).

Mobility Ability to move about. Mobility may depend on accessibility – a continuous, unobstructed path to move from one place to another.

Oversized Wheelchair

Any wheelchair that is larger in size and/or weight than a common wheelchair.

4.3.2 Accessibility Data Concept RequirementsAccessibility data concepts involve mobility, auditory and visual features related to different vehicle equipment (by mode), transit facilities where service is provided, and access (ingress and egress) to and between those facilities.

4.3.2.1 Accessibility Requirements by Mode (vehicle type)The key objective of accessibility onboard a transit vehicle is for individuals with mobility limitations to board and alight a transit vehicle (with assistance if necessary) and to ride securely. This requires a ramp, bridge or lift between the transit vehicle and transit stop (platform or pad) for persons with mobility aids (e.g., wheelchair). For non-wheelchair bound persons, assistance may include railings or clearly marked, priority seating. For persons in wheelchairs, this may include a clearly marked location for situating themselves while riding.

Based on Part 38 ADA Accessibility specifications for transportation vehicles (from 49 CFR Subtitle A (10-1-07 Edition, pp., 502-539), requirements for different modes are listed in Table 51. The details of each requirement may be found in Part 38 as referenced by the paragraph number in the column (header called: Para). Although requirements are common across modes, sometimes they vary due to the vehicle configuration. A transit agency shall designate its fleet or vehicle (or vehicles that service a

document.docx 107


route) as “accessible” if these criteria are met. With respect to this data specification, accessibility related to the vehicle indicates that the requirements described in Part 38 and related regulations are met.

The SDP data model assigns accessibility to route. Each route element includes a code that describes the ADA compliance with respect to mobility, visual and auditory access (see Section 4.3.2.7).

Most transit agencies also distinguish the type of ingress/egress equipment on board the vehicle, e.g., ramp (and low floor buses), lift, and platform bridge.

document.docx 108


Table 51: Part 38 ADA Accessibility specifications for transportation vehicle

Para Buses, vans, systems

Para Rapid Rail Vehicles

Para LRT Systems Para Commuter Rail Cars and Systems

Para Intercity rail cars and systems

Para Over the road Buses and other modes

38.21

General 38.51

General 38.71

General 38.91 General 38.111

General 38.151

General

38.23

Mobility aid accessibility(a) General(b) Vehicle lift(c) Vehicle ramp(d) Securement devices

38.83

Mobility aid accessibility(a) General(b) Vehicle lift(c) Vehicle

ramp or bridge plate

38.95 Mobility aid accessibility(a) General(b) Car lift(c) Car ramp or

bridge plate(d) Mobility and

seating location

38.125

Mobility aid accessibility(a) General(b) Car lift(c) Car ramp

or bridge plate

(d) Seating

38.159

Mobility aid accessibility(a) General(b) Vehicle lift(c) Vehicle ramp(d) Securement devices

38.25

Doors, steps and thresholds(a) Slip

resistance

(b) Contrast

(c) Door height

38.53

Doorways(a) Clear width(b) Signage(c) Signals(d) Coordinatio

n with boarding platform

38.73

Doorways(a) Clear width(b) Signage(c) Signals(d) Coordinatio


38.93 Doorways(a) Clear width(b) Passageway

s(c) Signals(d) Coordinatio


(e) Signage

38.113

Doorways(a) Clear

width(b) Passagew

ays(c) Signals(d) Coordina

tion with boarding platform

(e) Signage

38.153

Doors, steps and thresholds

38.27

Priority seating signs

38.55

Priority Seating 38.75

Priority seating 38.105

Priority seating signs

38.127

Sleeping compartment

38.29

Interior circulation, handrails and stanchions

38.57


38.77


38.97 Interior circulation, handrails and stanchions

38.115


38.155


document.docx 109


Para Buses, vans, systems

Para Rapid Rail Vehicles

Para LRT Systems Para Commuter Rail Cars and Systems

Para Intercity rail cars and systems

Para Over the road Buses and other modes

38.59

Floor surface 38.79

Floors, steps and thresholds

38.99 Floors, steps and thresholds

38.117

Floors, steps and thresholds

38.31

Lighting 38.81

Lighting 38.101

Lighting 38.119

Lighting I38.157

Lighting

38.33

Fare box

38.35

Public information system

38.61


38.87


38.103


38.121


38.161

Moveable aisle armrest

38.37

Stop request

38.107

Restrooms 38.123

Restrooms

38.39

Destination and route signs

38.63

Between-car barriers

38.85


38.109


document.docx 110

DRAFT Planning Requirements 25 August 2010

4.3.2.2 Accessibility Requirements for Transit Facilities (by Mode)The key objective of accessibility in a transit facility is to ensure mobility and access to public locations in and around the transit facility. For a transit stop to be considered accessible, a mobility-disadvantaged individual needs to successfully board or alight a transit vehicle from the stop or platform. Both physical attributes of the stop location and the type of vehicle boarding equipment must be considered.

Different vehicle types may have different requirements. For example for buses, the following types of questions might need to be asked:

At the stop, are individuals required to traverse curbs?

What is the size and construction product used for the stop pad?

Are there any additional physical barriers, such as telephone poles, lamps or other sidewalk obstructions, which might impede accessibility at the stop?

Are there ramps at the stop? If a bus uses a ramp or lift, can it be laid flat and is it accessible?

To this end, the dynamic relationship between the transit vehicle and its passenger loading equipment, and the stop (platform) is an important consideration in describing accessibility. In addition, for multi-car vehicles, the quality of boarding/alighting may become a significant issue, for example, obstacles and distance may prevent an individual from boarding or alighting a vehicle if the platform bridge is located at other end of the consist, or if a pole is in the way of deploying the ramp at a certain stop.

Additional Requirements for Rail (Rapid, Light and Commuter)

For a rail station to be considered accessible, a mobility-disadvantaged individual needs to be able to access the fare vending equipment, pay for the fare, navigate to the platform, and board the train. The individual needs to be able to disembark on a platform (at his/her destination) and exit the station. Depending on the physical nature of the transit facilities, various equipment and facilities may be required in order to make that station accessible to persons with mobility issues. The types of equipment are listed in Table 52.

With respect to platform accessibility, mobility includes both an individual’s ability to get to a platform, as well as that individual’s ability to traverse the gap between the platform and rail car to board a train. There are several issues with regard to the “gap”, including:

Gap size: the gap between the edge of the platform and the rail car. Gap drop: the difference in height between the edge of the platform and the rail car.

Table 52: Typical Equipment at a Rail Station and User’s Needs

Equipment User NeedsElevator Any persons with mobility issues, including those using wheelchairs and

scooters.

document.docx 111


Elevator size is a relevant attribute; some elevators can accommodate common wheelchairs but not oversized wheelchairs.

Escalator Persons who may have limited mobility (e.g. ability to walk short distances but not climb stairs) and who are not wheelchair bound.

4.3.2.3 Visual Accessibility (for Visually Impaired) for Transit Vehicle and FacilitiesThere are several issues related to providing accessibility services for the visually impaired. The ADA requires that bus stops be announced either by automated stop announcement technology or by the driver/operator.

The frequency of announcements may be driven by:

Stops Transfer points Major intersections Major destinations Intervals along a route sufficient to permit individuals with disabilities to be oriented to their

location (ADA requirement: 49 C.F.R. § 37.167(b)(1) – inclusive of first 5 bullets) Requested stops (ADA requirement: 49 C.F.R. § 37.167(b)(2))

Vehicles that arrive at transit stops should also be announced Buses usually make their own announcements at simple bus stops. Typically, a Public Address System located at a larger facility (location with more than one transit stop) is used to make announcements on arrival and departure times and locations (gates).

There are several problems with announcements, including:

A driver/operator turning off the automated stop announcements or opting not to announce stops.

Accurate announcement (sometimes the announcement is incorrect); Ability to modify or reset announcement (for detours or skipped stops) Volume and resolution. Update and maintenance of announcements when stops are added, removed or changed.

Traversal through a transit facility may depend on posting Braille signs in portals, stairwells, and hallways. Additional technologies are currently being developed that direct visually impaired persons through a facility. However, many facilities are not mapped to the extent that they can be used to generate directions for persons with or without visual challenges.

document.docx 112


4.3.2.4 Auditory Accessibility (for Hearing Impaired) on Transit Vehicles and at Transit Facilities

Individuals that are hearing impaired need assistance with messages that are typically communicated by drivers and stop announcement technology. Signs and flashing lights, stop request indicators, and other technologies help with persons who are aurally impaired. Trip information (arrivals, event instructions, delays, etc.) need to be provided on board the transit vehicle and at stops and stations.

4.3.2.5 Dissemination of Information about AccessibilityAnother component is how well customers can obtain information about accessibility. The information that is disseminated is within the scope of SDP, however, dissemination issues are related to functionality and implementation issues, and are outside the scope of these requirements.

4.3.2.6 Equipment Operation and ReliabilityFor all modes, accessibility is dependent upon the good maintenance and operations of equipment. There are several measures related to equipment performance and reliability. These include:

Overall reliability Operation reports Maintenance Policy and Implementation

o How soon are ADA requirements addressed? Regular and frequent maintenance checks of access equipment (49 C.F.R. §§

37.161) Buses with malfunctioning equipment to be removed from service before the

next service day are repaired promptly (49 C.F.R. §§ 37.163) Accessibility equipment to be made available to any person with a disability who

wishes to use it, including ambulatory riders (standees) whose disabilities can make climbing difficult (49 C.F.R. § 37.165(g))

o How frequently is maintenance performed?o What is the downtime due to maintenance? o How are maintenance issues tracked? What happens if a particular piece of equipment

has frequent issues? Does a particular type of issue occur frequently? Cleanliness Policy Communicate to customers when

out of serviceo How are customers notified

when equipment is out of service?

4.3.2.7 SDP Data ElementsThere are a few data concepts and elements that cover some of the business requirements. The Passenger Access Component covers equipment in a transit facility that describe access between floors and through facilities, for example, elevators,

document.docx 113

SDP Data Element: adaCompliance_cd “A type of ADA Compliance supported by a Transit Stop.” Enumerated values include:

notCompliant fullyCompliant mobilityChallengedAccess visuallyImpairedAccess hearingImpairedAccess mobility-VisuallyImpairedAccess visually-HearingImpairedAccess mobility-HearingImpairedAccess


escalators, moving walkways; it also includes stairwells and other obstacles to access. In addition, SDP includes an enumerated type Element that indicates whether a route or stop is accessible (see sidebar for adaCompliance_cd definition and values). The adaCompliance element covers the combinations of support equipment for different challenges as described in Table 53. However, the current reference model is missing key concepts needed to support transit planners. In particular, based on the requirements for accessibility data requirements, the following types of SDP Elements and Data Concepts are required:

(a) Extension to vehicle definition to include passenger loading equipment (including if operator assistance is needed);

(b) Extension to Connection Segment to identify “accessible” paths (between stops, stops and handicapped parking, etc.) including location of platform bridge plates and best vehicle entrance/exit locations.

(c) Update definition of adaCompliance_cd to apply to any type of facility or equipment (stops, pathways, vehicles, parts of facilities)

(d) Extension to Passenger Access Component to expand description it dimensions, capacity or other characteristic.

(e) Extension to Amenity to include descriptions and locations for Braille signs and other access amenities (not including passenger access components).

(f) Association between a transit vehicle and transit stop that identifies the relationship between the two entities, that is, the gap size and drop, obstacles to loading or deploying loading equipment (poles or pad surface).

(g) Reliability measures for facility and vehicle equipment.

Vehicle data concept (a) issues are incorporated in the Vehicle Model (see Appendix D: Vehicle Description Data Concept Description). The accessibility data requirement, consisting of an extension to the Connection Segment (b), adaCompliance_cd (c), Passenger Access Component definition (d) Amenity definition (e), and association between vehicle and stop are described in Appendix E: Accessibility Data Concept . Reliability and performance measures, although important, are out of scope of this project (at this time).

Table 53: adaCompliance Requirements

adaCompliance Enumerated Value

Requirement

notCompliant A transit agency shall designate its fleet, vehicle, transit facility (or plant component) when it is not compliant with Part 38.

fullyCompliant A transit agency shall designate its fleet, vehicle, transit facility (or plant component) with the value "fullyCompliant" when it is fully compliant with Part 38 of the ADA Accessibility specifications (summarized in Table 51 and described in Sections 4.3).

mobilityChallengedAccess A transit agency shall designate its fleet, vehicle, transit facility, (or plant component) with the value "mobilityChallengedAccess" when it complies only with the provisions related to wheel chair,

document.docx 114


mobility devices, and other mobility challenges. visuallyImpairedAccess A transit agency shall designate its fleet, vehicle, transit facility,

(or plant component) with the value "visuallyChallengedAccess" when it complies only with the provisions related to visual challenges, such as making announcements and other visual support tools (as summarized in Table 51 and described in Section 4.3..2.3).

hearingImpairedAccess A transit agency shall designate its fleet, vehicle, transit facility, (or plant component) with the value "hearingChallengedAccess" when it complies only with the provisions related to auditory challenges, such as signage and other auditory support tools (as summarized in Table 51 and described in Section 4.3.2.4).

mobility-VisuallyImpairedAccess

A transit agency shall designate its fleet, vehicle, transit facility, (or plant component) with the value "mobility-VisuallyChallengedAccess" when it complies with the provisions related to mobility and visual challenges (as summarized in Table 51).

visually-HearingImpairedAccess

A transit agency shall designate its fleet, vehicle, transit facility, (or plant component) with the value "visually-HearingChallengedAccess" when it complies with the provisions related to hearing and visual challenges (as summarized in Table 51).

mobility-HearingImpairedAccess

A transit agency shall designate its fleet, vehicle, transit facility, (or plant component) with the value "mobility-HearingChallengedAccess" when it complies with the provisions related to mobility and hearing challenges (as summarized in Table51).

4.3.3 Accessibility Data Set RequirementsAccessibility data sets needed to address regional transit planning may be characterized by the following questions:

What are the transit places and services that meet ADA requirements?

What are the transit places and services that don’t meet (or designate compliance with) ADA requirements?

What are the accessible paths and traversal times for specific or group services? (transfers between trips, parking to platform)

What are the accessible accommodations at a Transit Facility?

How many passenger access components (e.g., elevators) serve a specific transit stop (platform)?

document.docx 115


Other system information requests may include:

Number of key stations accessible (in a geographic region at a certain time of day) Number of stations (including but not limited to key stations) accessible (in a geographic region

at a certain time of day) % of total accessible stations Number of accessible routes Number of accessible vehicles in a fleet

All the requests (except requests related to vehicles) include a geographic dimension and for some a temporal dimension as well. For the most part, the Transit Network data set using an “attribute” related to accessibility equipment will provide the answer to all the questions posed by regional transit planners. In the case of vehicles (e.g., how many accessible vehicles in a fleet), a simple query of vehicles by appropriate attribute will result in a data set of the number and type of access equipment.

document.docx 116


4.4 Service Information Comparison Data Sets RequirementsA PDP result set may be defined for service information of the same type (service information and geographic / temporal dimensions) for two or more different time periods (that is activation- deactivation pairs). The comparison request does not perform a detailed comparison on a line by line basis. The result set contains packets of equivalently formatted data sets. An additional result sets describes the changes to the transit network. These are described in the section below.

4.4.1 Comparison Data Set RequirementsThe general comparison result set is composed of the spatial dimension data set and then two or more service information data set result sets; applicable service information data sets are illustrated in Figure 29 and described in Table 54. This information may be inserted into another desktop or statistics program to compare or apply to other analysis programs.

Figure 29: PDP Comparison Result Set Description

Where data set [1] and data set [2] are equivalent syntax only the content differs based on time period selection.

document.docx 117

PDP Comparison Result Set

Data Set [1]

activataionDateTime [1]

deactivationDateTime [1]

data set [1]

Data Set [2]

activataionDateTime[2]

deactivationDateTime [2]

data set [2]Spatial Dimension

Temporal Dimension


Table 54: PDP Comparison Result Set Description

Element Name

Element Reference or Attribute Name

Description

Data Set [i] activationDateTime Time period beginsdeactivationDateTime Time period endsdata set One or more result sets from list of Service

Information Result Sets (see Appendix G: List of Service Information Data Sets for list of allowed data sets).

Spatial Dimension

Includes Result Set from Section 3.1

Temporal Dimension

Includes only TimeDimension Element(s) from Section 3.2

document.docx 118


5 Validity CheckingThe result set and augmented SDP data model descriptions contained in this document shall follow the integrity checking requirements of the SDP [2, Section 6]. The SDP describes three levels for checking:

Level 1: Registration-ready

Level 2: Authorization-ready

Level 3: Regional Consistent

The three levels correspond to different validity tests to ensure proper semantic, syntax and other quality checks to validate the exchange of information. In the SDP Functional Requirements document, Table 55 summarizes the testing areas, expected test results and available downstream uses at the data registration/acceptance stage. General level descriptions and tests are included by reference through the SDP Functional Requirements Document [2, Section 6.1, 6.2 and 6.3]. Specific tests for each PDP results are listed in the following sections.

Table 55: Summary of Levels and Testing Criteria (adapted from 2, Table 73)

Level & Level Name

Testing Areas Test Result Next Step

Level 1: Registration-ready

Syntactic Integrity

Check correct syntax, values valid, and file complete. Checks described in [Reference 2, Section 6.1].

Ready to be registered and ready for logical consistency checks. In some cases, the files are now ready to be assembled into a complete set of [PDP result set] data

User may register file; File is available to progress to Level 2 testing.

Level 2: Authorization-ready

Semantic integrity and logical consistency

Check logical consistency as described in [Reference 2, Section 6.2 and related 5.1-5.9 checks listed below].

SDP documents are internally consistent and valid. The schedule data is ready to be used and included in the [TSIP]… as Level 2 qualified.

Revised [PDP] document is ready to be shared with requesters (consumers)

Level 3: Regional-consistent

Regional consistency

Check [PDP] Level 2 documents against regional data policies and conventions.

Ready to use in regional applications.

Revised [PDP] document is ready to be used in a regional application that requires regional information consistency.

Note: changes to [Reference 2, Table 73] are included in brackets.

5.1 Transit Network Data Set Checks<<insert here>>

document.docx 119


5.2 Time Period Data Set Checks<<insert here>>

5.3 Service Supplied Data Set Checks<<insert here>>

5.4 Service Consumed Data Checks<<insert here>>

5.5 Accessibility Data Checks<<insert here>>

5.6 Identifiers<<insert here>>

5.7 Association between Entities<<insert here>>

5.8 Code and Enumerated Values<<insert here>>

5.9 Other Checks<<insert here>>

6 MetadataMetadata describes the information contained in each data set. The requirements are structured to contain both the request and result set; consequently including most appropriate metadata in the data set. Additional data needed to fully describe the data set includes:

Identification of author and distribution

Description of use

Publication date

document.docx 120


These information elements will be included as an attribute of the PDP document as described in Table 56.

Table 56: Metadata Attributes inserted in PDP Document

Attribute Name Syntax Descriptionauthor string The name of the person generating the PDP document.authorContact string Contact email address for author.distributionList string List of persons separated by commas who received (or will receive) this

result set. This information shall be placed by the author. The list may contain email addresses or names of individuals.

purpose string The reason for generating the result set. For example, a ridership result set may be used for monthly ridership reporting. The purpose may state: “For June 2010 Ridership Report”.

publicationDate date The date the PDP document was generated.

The NYMTC Best Practices Model (BPM) Profile includes a detailed description of a metadata schema in Section 12.7.1.

<<add metadata schema for PDP>>

document.docx 121


Appendices

7 Appendix A: Acronyms and Terms

7.1 A-1: Acronyms

Term Description

ConOps Concept of Operations

Gazetteer, Transit Describes the places used by transit

ITS Intelligent Transportation Systems

NTD National Transit Database

NYSDOT New York State Department of Transportation

PDP Planning Data Profile

RSTWG Regional Stakeholders Technical Working Group

SDP Schedule Data Profile

TSDEA Transit Schedule Data Exchange Architecture

TSIP Transit Service Information Portal

7.2 A-2: GlossaryTerm Description SourceCorridor

8 Appendix B: References and ResourcesThe references listed below were reviewed or used in the development of this document.

[1] "TSIP Concept of Operations Planning Addendum" [Posted August 10, 2009] -- see http://ngtsip.pbworks.com/Planning.... recent posting.

[2] SDP Functional Requirement and Guidance Documents [2006 Version]Available at [http://www.consystec.com/tsdea/index.html]

document.docx 122


SDP Guidance Documents include: Executive Summary about SDP -- SDPGuidance_Part1.zip Part 2 -- Guidance on how to apply the functional requirements SDPG_Part2_Chapters in

PDF_v1.0Final.zip Quick Start (self extracting hyperlinked document) -- SDP_QS_v2.1.zip

[3] Fare Collection Data Profile. TBD

[4] National Transit Database. [http://www.ntdprogram.gov/ntdprogram/]

Reporting Manuals (including S-10, S-20, FFA-10)

Glossary

[5] Geographic Information Framework Data Content Standards Transportation Base Standard (Part 7) 22 July 2004. p., 7-5

[6] Keyhole Markup Language (KML) Documentation. http://code.google.com/apis/kml/documentation/kmlreference.html#polygon

[7] Portal System Requirements Document. TBD

[8] Okunieff, P., T. Adams, and N. Neuerburg. Best Practices for UsingGeographic Data in Transit: A Location Referencing Guidebook.Report FTA-NJ-26-7044-2003.1. FTA, U.S.DOT, 2005. [add link here]

[9] Draft Technical Memorandum, BPM Regional Transit Network Data Processing Procedures [transitdocuv4_020907.doc].

[10] TCRP Report 113: Using Archived AVL - APC Data to Improve Transit Performance and Management.

[11] Web Data Maintenance System Design

document.docx 123

http://code.google.com/apis/kml/documentation/kmlreference.html#polygon

http://ngtsip.pbworks.com/f/SDP_QS_v2.1.zip

http://ngtsip.pbworks.com/f/SDPG_Part2_Chapters+in+PDF_v1.0Final.zip

http://ngtsip.pbworks.com/f/SDPG_Part2_Chapters+in+PDF_v1.0Final.zip

http://ngtsip.pbworks.com/f/SDPGuidance_Part1.zip


9 Appendix C: Parking Facility Data Concept Description

9.1 Requirements Description for Parking Facility

9.1.1 Parking Facility DefinitionA parking lot facility is defined as a building, lot, or center used by transit patrons to store their vehicles while they use transit service, or pick up or drop off someone who transferred from or will transfer to public transit service. Table 57 depicts the requirements for the Parking Facility concept.

Table 57: Requirement Description for Parking Facility

# Requirement Category Description1 Uniqueness and name A parking facility may contain both an internal identifier and a public identifier2 Geometry and spatial

characteristics Parking facilities may be located using many different types of location references, e.g., spherical,

linear Parking facility may be represented by different geometries: point represented by a centroid, polygon,

polyline (for parking along the street), or a three dimensional structure. 3 Class and type A parking facility may be described as one of the following

Park and ride Kiss and ride Pick up parking (e.g., 15 minute parking)

The parking facility may be classified as a: Separate multiple-storied structure Open lot Underground multiple-storied structure Street parking such as waiting areas or metered parking Meter parking lot

4 Description A parking facility may include a general description or special notes related to parking services.

document.docx 124


5 Owner and operator A parking facility may include an owner, who may or may not be the transit operator The parking facility operator is the agent who acts for the owner to manage the parking facilities.

Contact information is typically available for both owner and operator.6 Capacity Supply (parking

by vehicle class and service type)

The parking facility capacity describes the number of parking spaces available for different vehicle classes and service types. The total number of spaces may not be available for all vehicle classes; some spaces may be reserved, under subscription or restricted to persons with different abilities.

Each parking space may be associated with its own supply attributes related to its vehicle class, service type, restriction, and cost. For example, lockers may be available to store bicycles; a driver of an electric car may be able to reserve a space with privileges to use a recharging outlet; a shared vehicle may have a permanently reserved space.

Parking may apply to different classes of vehicle such as consumer vehicles, motorcycles, vans, trucks, bicycles, electric cars, and more.

Service type describes the class of consumption available to the consumer. It may include: open space, reservation, subscription, valet, ADA restricted, and others.

7 Amenities Similar to the transit facility, the parking facility includes similar amenities such as Ticket Vending Machine / pay stations / attendant, gates, taxis, food, and restrooms.

8 Restrictions The parking facilities may restrict certain types of vehicle classes from using all or part of the parking facilities. Height / weight restrictions may apply to different levels, sections, or entrances/exits of the facilities.

9 Hours of Operations The parking facility may be closed during certain hours10 Cost There are different types of costs depending on several consumption factors including: hours used,

payment type, vehicle class, and service type. 11 Capacity Consumption Parking facilities will fill up between certain hours (e.g., 7 am to 3:30 pm). Different levels or parking

spaces may fill up sooner. Each parking space may be associated with its own consumption attributes related to status -- open,

occupied, reserved, and availability (open/occupied/reserved).12 “Junction” -- Connections

and Passage to Public Road Facility

The parking facility includes a junction (connection) between its driving facilities and the public streets. The junction may be an entrance, exit, or both. The two facilities might be linked via a restricted or unrestricted carriageway (driveway, private way). The parking facility may have a gate or obstacle restricting passage through the junction or restricted

carriageway. Passage through the junction may be associated with a time cost.

13 Access Components Similar to the SDP, a patron must travel from one facility (parking or transit) to the other. The passenger access components allow the traveler to move through hallways and between levels

document.docx 125


using specialize components “used to aid travelers to traverse from one level to another or from one end of a facility to another.” [SDP, p., 91]. According to the SDP, “examples include stairs, elevator, escalator, moving walkway.

The component may be described by direction (up, down, both), accessibility for people with disabilities or carts, and other characteristics such as traversal time (i.e., walk time).

14 Connections and Portals to Transit Facility

Similar to the SDP, the parking facility has entrances and exits (portals) and connection segments between the parking and transit facilities.

Portal Definition (adopted from SDP p., 93): A place where transit customers may enter or exit a parking facility. Examples include doors and gates to parking facilities

Connection Segment Definition (adapted from SDP, p., 97): A connection segment is a linear path allowing transit riders to move from a parking facility to a transit facility. The segment may be defined as a walking path, bike path, escalator, bridge, or other modal connection.

Connection Segment attributes may include distance, parking facility, transit facility, type, and connection instructions. Accessibility information in the form of a passenger access code maybe included; additionally, the connection segment may incur a traversal time cost that is based typically on distance and passenger access component used.

15 Associations A transit facility may be associated with more than one parking facility A parking facility may share plant components with a transit facility.

9.1.2 Conceptual Data ModelFigure 30 shows the data model for a parking facility adjacent to a transit facility. Several of the entities refer to SDP data concepts; the specific details are described in the sections below.

document.docx 126


Figure 30: Parking Facility Logical Data Model

document.docx 127


A ParkingFacility of a ParkingFacilityType provides ParkingServices. The ParkingFacility may be a structure or open lot; it may be a multi-level facility or a private drive where vehicles can drop-off and pick-up patrons (e.g., “kiss and ride”); or it may be on-street meters. The facility may provide parking for different types of vehicles including small and large automobiles, trucks and vans. The facilities may provide parking for bicycles and motorcycles. A park and ride facility may provide other types of services such as valet, storage lockers, washing, oil change, electric car charging, and more.

A ParkingFacility has an owner and operator. The owner and operator have contact information.

A ParkingFacility is located at a Location and has a footprint (polygon). It has a capacity for the number of vehicles it can store, as well as hours of operation, time when it is at full capacity and when it is not, and rules related to the types of vehicles that are restricted in the facility.

A ParkingFacility has a “schedule” of costs related to the different services it offers. A ParkingFacility is composed of one or more PlantComponents, including ParkingSpaces. A ParkingSpace is located somewhere in the ParkingFacility. It can accommodate different

vehicle types. It has a Status, that is, it is occupied, open, reserved, or otherwise classified. The ParkingSpace may include one or more services, such as a plug for an electric car, lock for a storage facility, oil change, or car wash.

Similar to a TransitFacility, the ParkingFacility PlantComponent is defined as one or more plantComponentTypes including:

Junction between the facility and a transportation network (e.g., walking, biking, vehicle), TransitFacility, PassengerAccessComponent, Portal, Amenity, and ConnectionSegment (between the ParkingFacility and TransitFacility).

Note: the TransitFacility, PassengerAccessComponent, Portal, Amenity and ConnectionSegment are all described in the SDP Functional Requirements Document [2].

9.1.3 Parking Facility Model DescriptionThe Data Elements that compose the ParkingFacility as illustrated Figure 30 in are described in Table 58. An example of the parking facility using sample data may be found in Attachment XXX.

Table 58: Description of Data Elements from ParkingFacility

Key Name / Role Name Description / UsagePK, M parkingID A unique identifier for a parking facility within a transit agency’s

enterprise system or within a regional system.M publicParkingName A designation used by the public for a parking facility.FK, M locationID A location identifier (found in the Location table) that describes

document.docx 128


the physical location (or centroid) of the parking facility.FK footprint A polygon identifier (found in the TransitPolygon table) that

describes the physical area covered by the parking facility. ownerName The name of the owner of the parking facility.ownerContact The contact information related to the owner of the parking

facility.M operatorName The name of the operator of the parking facility.M operatorContact The contact information related to the owner of the parking

facility.M hrsOfOperation The time when the Parking Facility is open and vehicle can enter

and leave. The range of hrsOfOperations is zero (0) to twenty four (24).

M costDescription A description of the cost paid by a consumer using the parking facilities. The cost may be a single number, but most likely is a table or schedule based on services. Alternatively, the Fare Collection Data Profile model may be inserted into this field

FK, M parkingFacType A classification for the physical structure of a Parking Facility. The types may include: on-street – public way, open lot, covered lot, multi-level structure, pull out – private way.

restrictionDescription A description of the rules and restrictions related to usage of the facilities. For example, height and weight restrictions, overnight parking restrictions.

fillTime_from Approximate time (in hh:mm) the parking facility is full.fillTime_to Approximate time (in hh:mm) the parking facility transitions from

full to open.PK indicates primary and identifying keyFK indicates foreign key or reference indexM indicates mandatory element; if “M” is not present then the data element is optional.

9.2 Related Parking Facility Data TypesRelated Parking Facility Data Types includes the following data elements:

ParkingFacilityType ParkingServicesType and Association ParkingSpace and related data types Junction

9.2.1 ParkingFacilityTypeParkingFacilityType Definition: A classification for the physical facility of a parking facility. Facility types may include open lot, on-street parking space, off-street parking on a private carriage way or pull out, patron dropoff/pickup location, garage structure, and more.

document.docx 129


Table 59: Description of a ParkingFacilityType

Key Name / Role Name Description / UsagePK, M parkingFacType_cd An enumerated type that uniquely describes, through the use of a

code, a type of parking facility.M parkingFacDescription An explanation or definition of the parkingFacType.

9.2.2 ParkingServicesType and AssociationA Parking Facility may offer more than one service at the facility. To that end, there is a data type that describes the service type (ParkingServicesType) and another that associates one or more service types with a parking facility (parkingServicesAssociation).

ParkingServicesType Definition: A classification for the provisions offered by a parking facility. Services offered may relate to the vehicle type or class, amenities offered by the facility such as bicycle storage locker and locks, valet services, “kiss and ride”, parking subscription and reservation services, and more.

Table 60: Description of a ParkingServicesType

Key Name / Role Name Description / UsagePK, M parkingServicesType_cd An enumerated type that uniquely describes through the use of a

code services offered at the parking facility.M parkingServicesDescription An explanation or definition of the parkingServicesType.

ParkingServicesAssociation Definition: The relationship between a Parking Facility and the services it offers, for example, vehicle maintenance services such as car wash and detail or oil change.

Table 61: Description of ParkingServiceAssociation

Key Name / Role Name Description / UsagePK, FK, M parkingServicesType_c

d[from ParkingServicestype]

PK, FK, M parkingID [from ParkingFacility]O comment A memo field that describes any special issues related to the

provision at the parking facility.

9.2.3 ParkingSpaceDefinition: A storage location for a single transport conveyance in a transit parking facility. A parking space may be a type of space and have a status.

Table 62: Description for ParkingSpace

Key Name / Role Name Description / UsagePK, M parkingSpaceLevel A unique identifier for a parking level in a transit parking facility.PK, M parkingSpaceNumber A unique identifier for a storage space for a transport conveyance

document.docx 130


(car, bike, motorcycle) in a transit parking facility.O restriction A constraint put on a parking space in a transit facility. For

example, a space may be restricted for persons with disabilities.

Table 63: Description for ParkingSpaceType

Key Name / Role Name Description / UsagePK, M

parkingSpaceType_cd An enumerated code that classifies a parking space in a transit parking facility.

M parkingTypeDescription A description for the parkingSpaceType_cd.

Table 64: Description for ParkingStatus

Key Name / Role Name Description / UsagePK, M status_cd An enumerated code that classifies the status of a parking space

in a transit parking facility. Among the default types include: occupied, reserved, open, or otherwise classified.

M description A short explanation of about the parking statusO fromTime The (date) time whence the status began (begins).O toTime The (date) time at which the status ends (ended).O dayType (from SDP) The enumerated code that is used to classify service

for the day.FK parkingSpaceNumber A unique identifier for a parking level in a transit parking facility.

(inherited from ParkingSpace)FK parkingSpaceLevel A unique identifier for a storage space for a transport conveyance

(car, bike, motorcycle) in a transit parking facility (inherited from ParkingSpace).

Definition for ParkingSpaceServicesAssociation: assignment of one or more ParkingSpaceTypes to one or more ParkingSpaces.

Table 65: Description for ParkingSpaceServicesAssociation

Key Name / Role Name Description / UsagePK, M parkingSpaceType_cd An enumerated code that classifies a parking space in a transit

parking facility.PK, FK

parkingSpaceNumber A unique identifier for a storage space for a transport conveyance (car, bike, motorcycle) in a transit parking facility

comment A description related to the type of parking space. For example, this field may describe the type of bike rack or locker security characteristics.

FK parkingSpaceLevel A unique identifier for a parking level in a transit parking facility. (note – this field is not mandatory because some facilities do not have indicators for levels).

document.docx 131


9.2.4 JunctionDefinition: A connection or intersection between two transportation modes (e.g., walking path and parking facility; bicycle lane and street network).

Table 66: Description for a Junction

Key Name / Role Name Description / UsagePK, M junctionID A unique identifier for a junction within a transit agencies

enterprise system or within a regional system.PK, FK, M

junctionType_cd An enumerated code that classifies a connection or intersection between two transportation modes

O locationDescription Describes the location at where the junction occurs.M locationID (from SDP) A unique identifier from the Location element that

describes the location reference.O streetName If available, the street or intersection where the junction is.O gated A boolean that indicates if the junction is gated. For example, an

entrance to a parking facility from a road.

Table 67: Description for a JunctionType

Key Name / Role Name Description / UsagePK, M junctionType_cd An enumerated code that classifies a connection or intersection

between two transportation modes (e.g., walking path and parking facility; bicycle lanes and street network).

M junctionTypeDescription A description for the junctionType_cd.

9.3 Reused SDP Related Data TypesThis section summarizes the data types that are defined in the SDP Functional Requirements Document [2] that may be reused for parking. They include:

Amenity [2, Section 4.8] Passenger Access Component [2, Section 4.8] PlantComponent [2, Section 4.8] Portal [2, Section 4.8] TransitFacility [2, Section 4.8] TransferClusterName and ConnectionSegment 2, [Section 4.9]

To use ConnectionSeg for facilities other than TransitStops, the current definition should be updated to the following:

“A ConnectionSeg is a linear path allowing transit riders patrons to move from one TransitStop, TransitFacility or ParkingFacility to another. The segment may be defined as a walking path, bike

document.docx 132


path, escalator or other modal connection. Attributes include distance, fromStopLocation, toStopLocation, and connection instructions. Accessibility information in the form of a passenger access code may optionally be provided for ConnectionSegs.”

This change does not require any revision to the existing SDP data type description [2, p., 97].

Note: the cross outs show the words that are eliminated while the red indicates the words that are included.

10 Appendix D: Vehicle Description Data Concept Description

10.1 PTV Data Concept and Model DescriptionThe existing SDP Public Transit Vehicle (PTV) data concept may be extended to meet the PDP needs. The PTV model is extended to include the PTV Type and several rail related data concepts as depicted in Figure 31.

Definition of PTV Type or Vehicle Passenger Fleet TypeA vehicle passenger fleet type is a category of conveyance assigned to public transportation revenue service that carries public transportation patrons.

document.docx 133


Figure 31: Public Transit Vehicle Logical Data Model

Legend for Figure 31–PK = primary keyFK = foreign key Identifying keys are listed in the middle area of each entityBolded line = mandatory fieldPTV = public transit vehicle

The model is described as follows:

A Vehicle Fleet Type (PTV_Type) has certain capacity characteristics including total passenger capacity, standing, seat and wheel chair slots (wcCapacity) available on the specific vehicle type. A passenger transit vehicle (PTV) is a type of revenue vehicle in the fleet, including equipment

document.docx 134


on board that meets ADA compliance (adaCompliance_cd) and the access equipment for loading passengers (accessEquipment). The PTV assignments (BLOCK for buses only) are assigned based on the capacity, vehicle configuration (PTV_Type), or by specific bus including the ADA compliance needs.

Similarly, each rail car (Rail_PTV) is a type of passenger vehicle. A rail car is assigned to a train (Consist), and is assigned an order in the train. The Consist is assigned to specific work (RSU) which is known to passengers (TRIP).

Block, PTV and Trip are defined in the SDP [2, Sections 4.13 and 4.7] with the exception of adding the attributes to these existing SDP elements (see Table 68).

Table 68: Enumerated Elements to Support ADA Compliance on PTV

Enumerated Type Name

Definition Extensions to SDP Elements

adaCompliance_cd “Indicates compliance with specific ADA requirements related to different disabilities.”Values include:


PTV: adaCompliance

Rail_PTV: adaCompliance

BusVehicleWorkAssignment:adaComplianceNeeds

accessEquipment_cd

Equipment on-board a transit vehicle (PTV or rail_PTV) that enables passengers with disabilities to board or alight from a transit vehicle in revenue service. Values include:

Lift [lift] Ramp [ramp] Low floor bus [lfb] Platform bridge [bridge] None [none]

PTV: accessEquipment

Rail_PTV: accessEquipment

Legend for Table 69-Table 72:

PK = Primary KeyM = Mandatory field

PTV_Type DefinitionA PTV_Type describes the capacity of a conveyance assigned to public transportation revenue service that carries public transportation patrons.

document.docx 135


Table 69: Description of PTV_TypeKey Role/Name DefinitionPK vehicleFleetTypeID A unique identifier that distinguishes this type of public

transport vehicle type or vehicle fleet type.M name The name of the vehicle type.M description A short description of the vehicle type.

vehicleType The type of vehicle in the fleet. maxCapacity The maximum number of passengers allowed on the vehicle

(that includes seated and standing).seatingCapacity The number of seats available for passenger seating.standingCapacity The number of people allowed to stand in the vehicle.

O wcCapacity The number of slots that can restrain wheel chairs or motorized scooters on the vehicle.

Rail_PTV DefinitionA Rail_PTV is an instance of a rail car of vehicleFleetType.

Table 70: Description of Rail_PTV

Keykey Role/Name DefinitionPK carID A unique identifier for a rail car.PK, FK vehicleFleetTypeID A reference to the identifying key from PTV_TypeO adaCompliance Describes the compliance of this PTV to ADA regulationsO accessEquipment Describes the type of access Equipment that is supported by

this PTV. Includes wheelchair tie downs, hand-holds, annunciator, signage, etc.

O description A short description for the rail car.Note: vehicleFleetID is defined in PTV_Type

Consist DefinitionThe rail cars that make up a train.

Table 71: Description of Consist

key Role/Name DefinitionPK seqNo The order in which the rail cars are assigned in the consist.PK, FK vehicleFleetTypeID A reference to the identifying key from PTV_Type.PK, FK, M

rsuID A reference to the identifying key from RSU.

PK, FK, M

carID A reference to the identifying key from Rail_PTV.

FK tripID A reference to the identifying key for which this trip operates.

document.docx 136


FK dayType A reference to the type of day on which this trip operates.Note: all fields that are related as a “foreign key” (FK), are defined in their primary entity definitions

Rai Service Unit DefinitionThe Rail Service Unit (RSU) is a train (including locomotive and rail cars) that is assigned to specific work.

Table 72: Description of RSU

Key Role/Name DefinitionPK, M rsuID A unique identifier that distinguishes the rail service unit.PK, FK, M

tripID A reference to the identifying key for which this trip operates.

PK, FK, M

dayType A reference to the type of day on which this trip operates.

M carCount The number of rail cars in the RSU.

Example of Rail Consist for Subway “A” DivisionThis example is based on the NYCT subway “A” Division Subway Loading Guidelines. The example shows the weekday Peak loading capacity for the 10-car consist that operates during weekday peak hours (7:00 AM – 9:00 AM, and 4:00 PM – 6:30 PM). All names and values are adopted and not specified by NYCT.

Table 73 shows the A-1 vehicle fleet type that is subject to the “A” Division Car loading guidelines

Table 73: Exampleof PTV_TypeKey Role/Name ExamplePK vehicleFleetTypeID A-1M name “A” Division CarM description Subway loading guidelines for the “A” Division Car weekday

Peak (7:00-9:30 AM, 4:00-6:30 PM); “A” Division has 51-foot cars

M vehicleType R142AM maxCapacity 110O seatingCapacity 38 O standingCapacity 72O wcCapacity

Table 74 shows an example of a car (Rail_PTV) that is part of the A-1 fleet (PTV_Type).

Table 74: Example of Rail_PTV

Key Role/Name ExamplePK carID 100PK, vehicleFleetTypeID A-1

document.docx 137


FKO description Typical “A” Division Car

Table 75 shows the ten cars from (carID) 100 to 109 (from vehicleFleetTypeID (A-1) that operate tripID w705 on weekdays from RSU (rsuID) “2”.

Table 75: Example of Consist

Key

Role/Name

Ex-1 Ex-2 Ex-3 Ex-4 Ex-5 Ex-6 Ex-7 Ex-8 Ex-9 E-10

PK seqNo 1 2 3 4 5 6 7 8 9 10PK, FK

vehicle Fleet TypeID

A-1 A-1 A-1 A-1 A-1 A-1 A-1 A-1 A-1 A-1

PK, FK

rsuID 2 2 2 2 2 2 2 2 2 2

PK, FK

carID 100 101 102 103 104 105 106 107 108 109

FK tripID w705 w705 w705 w705 w705 w705 w705 w705 w705 w705FK dayType week

dayweekday

weekday

weekday

weekday

weekday

weekday

weekday

weekday

weekday

Finally, the RSU (rsuID) “2” is assigned to tripID w705 that operates on weekdays. The RSU operates with 10 cars.

Table 76: Example of RSU

Key Role/Name ExamplePK rsuID 2PK, FK tripID w705PK, FK dayType weekdayM carCount 10

BusVehicleWorkAssignment DefinitionThe association between the BLOCK (work assignment for a bus from pull out to pull in on a daily basis) with either the PTV or PTV_Type.

Note: the fields in the BusVehicleWorkAssignment are defined by BLOCK, and PTV or PTV_Type. (This entity is an abstract artifact to show which PTV / PTV_Type entity will be assigned to the Block. In fact, at different times during the scheduling process, the PTV_Type reference may be replaced with the PTV information.

document.docx 138


document.docx 139


11 Appendix E: Accessibility Data Concept ExtensionsBased on requirements described in Section 4.3, the data requirements include several types of extensions to existing SDP data concepts and elements, and some additional elements. The list of data concepts that drive the data described in this section include:

adaCompliance_cd

o to apply to any type of facility or equipment (stops, pathways, vehicles, parts of facilities)

Connection Segment o Identify “accessible” paths (between stops, stops and handicapped parking, etc.) o Location/identification of best path for mobility-challenged persons.

Passenger Access Component o Include dimensions, capacity or other characteristics.

Amenity o Include descriptions and locations “access” amenities

Vehicle-Stop Associationo Gap size and dropo Obstacles to loading or deploying loading equipment (poles or pad surface)

11.1 adaCompliance_cd DefinitionIn extending the number of entities/elements that use adaCompliance_cd, the definition should be updated to read:

“ADA Compliance supported by a transit facility, asset, or revenue vehicle.”

The enumerated values shall stay the same to include:


The requirements related to assigning a value to a transit vehicle, revenue vehicle or other asset are defined in Table 53: adaCompliance Requirements.

document.docx 140


11.2 Connection Segment ExtensionsThe Connection Segment should be extended to designate preferred path for persons with disabilities. To that end, the Connection_Seg entity (ConnectionSegment element) will require an additional attribute called connectionType. The connection type identifies preferred paths for different accessibility needs such as persons with wheelchair and mobility issues, persons with carts or buggies, persons who want to minimize the number of stairs, persons with hearing or vision challenges, etc. The Connection Segment data concept is illustrated in Figure 32 and described in Table 77.

Figure 32: Extension to Connection_Seg for Data Concept Access Attributes

A connect segment (Connection_Seg) shows a path that belongs to a transfer cluster between transit stops, transit stop-parking, or between any two transit places (Locations). The connection segment describes the path (instructions), the type of mobility services available (passengerAccessCode) along the path such as an elevator, escalator, moving walkway, and optionally, the distance from transit place to transit place and a link to a diagram (map) that shows the path. The connection segment may also designate the path (connectionType) as the best path for different accessibility needs, including persons using mobility devices, persons using carts, pushing buggies, or pulling luggage; persons who want to minimize stairs; person who want the shortest path, etc.

Table 77: Extension to Connection_Seg Data Concept to include Access Attributes

Key Name DescriptionM connectionID A unique number assigned to a connection segment that distinguishes

document.docx 141


(PK) each path between two locations such as transit stops (boarding areas), stop / parking, or between two other transit places that is associated with a Transfer Cluster.

O (FK)

transferClusterName A unique alphanumeric identifier for a transfer cluster.

M (FK)

toStop [location_toStop]

Ending transit place location of the connection segment. The location may be a stop, parking, or other transit place (referenced in the Location table).

M (FK)

fromStop [location_fromStop]

Starting transit place location of a connection segment. The location may be a stop, parking, or other transit place (referenced in the Location table).

M passengerAccessCode A code that identifies the type of passenger access component. The component may be stairs, elevator, escalator, moving walkway, or other link between two points in a transit facility. [The codes are defined in the Passenger Access Type entity.]

M instructions A set of directions to traverse a connection segment.O distance The length between two pointsO mapURL A uniform resource location (URL) that links a map that displays a

connection segment.O connectionType A code (enumerated type) that describes the category of connection

segment. The connection type may be mobility access enabled, minimum stairs, “cart” / buggy preferred, etc. Code values shall include: fullMobility – only elevators, ramps, and lifts;partMobility – may include curbs, escalators and other small obstacles to mobility;fullAccessible – fully mobile, well documented with signs, Braille instructions and announcement aids;partAccessible – partMobility and may not include announcements and signs throughout the path;notAccessible – has stairs and other obstacles to traversal.

11.3 Passenger Access Component Data Concept ExtensionThe Passenger Access Component (PAC) data concept currently includes information on the availability of specific vertical and horizontal people moving equipment such as elevators, escalators and moving walkways. The entity includes the presence of the equipment, but not details of its characteristics. The accessDesc field is a “catch-all” attribute which may be used by a data provider to document its characteristics in a free form text. This Planning PDP can formalize the tags to insert in that memo field as listed in PAC_Characteristics or define a separate entity associated with the PAC data concept. Figure 33 shows the PAC_Characteristics entity and current list of attributes. The format for these attributes is open.

document.docx 142


Figure 33: Passenger Access Component and Amenity Data Concept Extensions

11.4 Amenity Data Concept ExtensionAmenities are not necessarily associated as access-enabled. By including the attribute adaCompliance_cd (see updated definition in Section 11.1), a Data Provider may designate an amenity as compliant with ADA requirements. Figure 33: Passenger Access Component and Amenity Data Concept Extensions shows the adaCompliance attribute in the Amenity data concept. The adaCompliance value is not applicable to every Amenity (as currently described by the amenityCode_cd).

11.5 Transit Vehicle Extension and Vehicle-Stop AssociationIn Figure 31 and Table 68, the Transit Vehicle model was extended to include PTV and Rail_PTV accessEquipment. The requirements also require an entity that can relate the transit vehicle in revenue service to equipment reliability and other customer communications related to the particular equipment operations and their use by person with accessibility challenges. To this end, Figure 34 shows a new

document.docx 143


entity called Accessibility_Status that extends the transit vehicle data concept to include an association between PTV and Rail_PTV and its access equipment, and related equipment reliability status, and/or customer communications. (Note: associated entities are not included in this model.)

Figure 34: Association Entity extending Transit Vehicle Data Concept

document.docx 144


12 Appendix F: NYMTC Best Practices Model PDP “Profile”

12.1 IntroductionThis section describes the input formats that may be used to feed the NYMTC Best Practices Model. These data set formats and data content support transit data required by the BPM. The TSIP will support several specialized formats and the NYMTC BPM formats are among these formats.

12.2 ScopeAlthough not all the BPM transit file formats will be provided via the TSIP, the following BPM data concepts are included in the descriptions below:

Section 13.3 -- Association/translation tables for Values in the ROUTE Record Format (BPM, Table 3-9) for

o Modeo Mode IDo Fare Code

Canned criteria for the following selection typeso Designated Time Periods (AM/Mid/PM/Eve/Night)o Service Headwayo Capacityo Route Name

12.3 ROUTE Record Format -- TSIP Translation Code Values for BPMThe ROUTE Record Format is a core data table for the BPM. Many of the code values for Mode, Mode 1 and Mode 1 for Fares do not change often, and they are directly related to one or more code values in the TSIP data profiles. Sections 13.2.1-13.2.3 contain lookup or translation tables that associate ROUTE code values with TSIP code enumeration combinations. The ROUTE code values and TSIP code enumeration values are listed in a table, side-by-side, to show the relationship between BPM and TSIP values.

12.3.1 ROUTE Mode Translation The ROUTE Record for Mode lists six values for BPM “mode”. Mode described in BPM is a combination of the mode_cd (associated with a route) and serivceType_cd (associated with a trip). For example, NYCT may include both regular and limited bus service under the same route identifier (e.g., M1). TSIP/SDP will distinguish the difference by the pattern and serviceType code value (as listed in Trip).

The allowed values for mode are listed in Mode Definition. The allowed values for serviceType_cd are listed in Service Type Definition. Service type is optional, so if is not included, then the default is regular service.

document.docx 145


Table 78: Association between BPM Mode and TSIP code values

BPM Mode Types TSIP / SDP Enumeration PairsMode I*4 Mode mode_cd serviceType_cdLocal bus 1 all operators excluding

ferry operatorsMB regular

Limited bus 2 nyct bus MB limitedExpress bus 3 all operators MB expressCommuter rail 4 LIRR, MNR, NJT CR <any>Subway 5 NYC Subway, PATH,

Newark City SubwayHR <any>

Ferry/tram/ferry shuttlebus

7 FB [for ferry boat]LR [for tram]

<any>

12.3.2 ROUTE New Mode 1 TranslationThe ROUTE Record for New Mode 1 lists six values for BPM “new mode 1”. New Mode 1 described in BPM is a combination of agency (agencyAcronym), mode_cd (associated with a route) and serivceType_cd (associated with a trip). For example, NYC Subway Express requires information about the agency, mode and service.

The allowed values for mode are listed in Mode Definition. The allowed values for serviceType_cd are listed in Service Type Definition. When service type is not present the default value is “regular.”

<<insert acronym from 511NY agencyID and acronym table>>

Table 79: Association between BPM New Mode 1 and TSIP Values

BPM New Mode 1 Code identifying Operator TSIP / SDP TypesagencyAcronym mode_cd serviceType_cd

1= NYC Local Bus NYCT MB regular2= NYC Limited Bus NYCT MB limited3= NYC Express Bus NYCT MB express4= NYC Subway Local NYCT HR local5= NYC Subway Express NYCT HR express6=Westchester Local Bus (Bee Line) MB local7=Westchester Express Bus (Bee Line) MB express8=Huntington Area Rapid Transit Bus MB regular9=City of Long Beach Local Bus MB regular10=MTA Long Island Bus Local LIB MB regular11=Suffolk County Local Bus SCT MB regular12=Orange County Private Express Bus OCT MB express13=Westchester County Private Express Bus MB express14=Transport of Rockland Local Bus TOR MB local15=Transport of Rockland Express Bus TOR MB express16=NJ Transit Local Bus (including Privates) NJT MB regular17=NJ Transit Express Bus (including Privates) NJT MB express18=PATH PATH HR regular

document.docx 146


BPM New Mode 1 Code identifying Operator TSIP / SDP TypesagencyAcronym mode_cd serviceType_cd

19=Newark City Subway HR? regular20=Greater Bridgeport Local Bus MB regular21=Norwalk Transit Local Bus MB regular22=CT Transit New Haven Local Bus CT MB regular23=Milford Transit Local Bus MB regular24=Meriden Local Bus MB regular25=Northeast Transportation Local Bus MB regular26=Westport Transit Local Bus MB regular27=Houstatonic Local Bus MB regular28=CT Transit Stamford Local Bus MB regular29=Roosevelt Island Tram LR regular30=NYCDOT Ferry NYCDOT FB regular31=NY Waterways Ferry FB regular32=Ferry Shuttle Bus MB regular33=MNR Local Commuter Rail MNR CR regular34=MNR Express Commuter Rail MNR CR express35=LIRR Local Commuter Rail LIRR CR regular36=LIRR Express Commuter Rail LIRR CR express37=NJT Local Commuter Rail NJT CR regular38=NJT Express Commuter Rail NJT CR express39=Clarkstown Local Bus MB regular40=Dutchess CTC Local Bus MB regular41=Dutchess Express Bus MB express42=Dutchess Loop Local Bus MB regular43=Village of Kirvas Joel Local Bus MB regular44=Middletown Local Bus MB regular45=Newburgh Local Bus MB regular46=Poughkeepsie Local Bus MB regular47=Putnam County Local Bus MB regular

(BPM missing Tappan Zeexpress? MTABus?)

12.3.3 ROUTE Mode ID for Fare Processing TranslationThe ROUTE Record field that designates the fares may be defined by the Fare Collection Data Profile. The Profile will define cost for a “regular” ride for agencies that charge a flat fare.

<<Note: FCDP will need to include a query to display data for fare gradations such as itinerary cost between 0 and $.50; greater than $.50 to $.75; greater than $.75 to $1.00; etc.>>

Table 80: Association between BPM Mode ID for Fare Processing and TSIP Elements

BPM TSIP / FCDPMode ID for fare processing agencyAcronym & mode_cd

& serviceType_cdFCDP [TBD]

1 = Commuter Rail (LIRR, MNR, and NJT Rail) <LIRR, MNR, NJT> & CR & <any>

2 = NYC Local ($1.50) Bus NYCT & MB & <not express> 3 = NYC Express ($3.00) Bus NYCT & MB & express

document.docx 147


BPM TSIP / FCDPMode ID for fare processing agencyAcronym & mode_cd

& serviceType_cdFCDP [TBD]

4 = PATH PATH & <any> & <any> 5 = Suburban Bus Charging Approximately $.50 <not NYCT> & MB & <any> requires API from FCDP 6 = Suburban Bus Charging Approximately $.75 <not NYCT> & MB & <any> requires API from FCDP 7 = Suburban Bus Charging Approximately $1.00 <not NYCT> & MB & <any> requires API from FCDP 8 = Suburban Bus Charging Approximately $1.25 <not NYCT> & MB & <any> requires API from FCDP 9 = Suburban Bus Charging Approximately $1.50 <not NYCT> & MB & <any> requires API from FCDP 10 = Suburban Bus Charging Approximately $1.75 <not NYCT> & MB & <any> requires API from FCDP 11 = Suburban Bus Charging Approximately $2.00 <not NYCT> & MB & <any> requires API from FCDP 12 = Suburban Bus Charging Approximately $2.50 <not NYCT> & MB & <any> requires API from FCDP 13 = Suburban Bus Charging Approximately $3.00 <not NYCT> & MB & <any> requires API from FCDP 14 = Suburban Bus Charging Approximately $4.00 <not NYCT> & MB & <any> requires API from FCDP 15 = Suburban Bus Charging Approximately $5.00 <not NYCT> & MB & <any> requires API from FCDP 16 = Suburban Bus Charging Approximately $6.00 <not NYCT> & MB & <any> requires API from FCDP 17 = Ferry <any> & FB & <any> 18 = Ferry Bus <add here> & MB & <any> 19 = NYC Subway NYCT & HR & <any>Where & indicates a logical “AND”.Where <any> indicates any of the type of data values allowed.Where <not xxx> indicates any of the type of data values except xxx.

12.4 Time Period Query DescriptionA canned query that describes the Time Period (as specified in Section 3.2) is described below. The BPM representation for default time periods is defined in [9, pp., 74] and listed in Table 81.

Table 81: BPM Time Period Description

Time Period Name Description (from – to; duration in minutes)From [9, pp., 74]

AM Peak Period 6AM to 10 AM=240 minutesMidday Period 10AM to 4 PM=360 minutes PM Peak Period 4PM to 8 PM=240 minutesEvening Period 8PM to 1AM=300 minutesNight Period 1AM to 6AM=300 minutes

The PDP Time Period definition, based on the TimePeriod data concept (Table 18) is defined in Table 82.

Table 82: BPM TimePeriod Data Instance

Field name AMPeak Midday PMPeak Evening NightperiodID 1 2 3 4 5periodName AM_BPM MID_BPM PM_BPM EVE_BPM NT_BPMperiodDescription 6AM to 10

AM=240 minutes

10AM to 4 PM=360 minutes

4PM to 8 PM=240 minutes

8PM to 1AM=300 minutes

1AM to 6AM=300 minutes

document.docx 148


inclusive true true true true truetimeBegin 21600 36000 57600 72000 3600timeEnd 35999 57599 71999 3599+(86400) 21599dayType weekday weekday weekday weekday weekday

12.5 Headway DescriptionService headway information is specified in the ROUTE Record. Five Headway values are selected per route (by agency). The process for selecting service headway is as follows:

1. For each route by agency2. For a new schedule version (or time dimension – start to end dates)

o Constrain the day types to weekdays (Monday through Friday)3. For each time period

o Using the five time periods described in Table 824. Select Service Headway data set

o By agencyID.o For each routeID and routeDirection.o By a common location (stop).

5. Generate Service Headway data set query and the three files (see Tables 78 to 80)6. Generate the metadata / query file for the result set.7. Bundle the Service Headway and metadata file result sets in a zipped file using the following

naming convention: PDP_SVC-HDWY_<time-period>_<agencyAcronym>_<scheduleVersion>_<publication date>.zip

o The values in < > are parameters that represent selections made in the process steps above.

The process should be implemented in a module and saved so that BPM analysts may query the TSIP database once for the all the data they require.

For each agency, a result set should contain three comma delimited files. The files should be specified as listed in Table 83 to Table 85.

Table 83: Service Headway (Svc-Hdwy) File Description

Svc-Hdwy File Field Name Descriptionmetadata Mandatory. File name for metadata file.bpm_timePeriod AM_BPM, MID_BPM, PM_BPM, EVE_BPM, NT_BPMavgServiceHeadway Mandatory. The average service headway based on the data

provided in the TripList file.

The equation used to generate average Service Headway is

document.docx 149


specified in Equation 2: Average Service Headway.routeID Mandatory. (Identifying key). A unique identifier for a route for

which the service headway is calculated.routeDirection Mandatory. (Identifying key). The direction of service along the

route for which the service headway is calculated. routeDirection may be specified for the first or second direction only.

patternID Optional. A unique set of events and/or stopping points in a specified direction along a route.

A single pattern along the route (by route direction) may be specified for the calculation. For example, a planner may wish to calculate the service headway for the express inbound pattern.

commonTripTimeLocation Mandatory. (Identifying key). A specific location along the route from which the trip time information is calculated.

The location references a locationID in the Location element.numberTrips Mandatory. (checksum). The number of trips in the TripList file.File header format for PDP_Svc-Hdwy.csv:

[metadata, bpm_timePeriod, avgServiceHeadway, routeID, routeDirection, patternID, commonTripTimeLocation, numberTrips]

Table 84: Service Headway TripList File Description

TripList File Field Name Descriptionmetadata Mandatory. File name for metadata file.bpm_timePeriod AM_BPM, MID_BPM, PM_BPM, EVE_BPM, NT_BPMtripID Mandatory. (Identifying key). A unique identifier for a trip that

was used to compute the avgServiceHeadway.routeID Mandatory. (Identifying key). A unique identifier for a route

that is associated with the trip.patternID Mandatory. (Identifying key). A unique identifier for a pattern

that is associated with the trip.

If Svc-Hdwy patternID is included, then this field must match the field in that file.

dayType Mandatory. (Identifying key). Service that is delivered on the type of day. The BPM only uses trips that occur on weekdays (Monday through Friday).

tripName Optional. A common name used to designate the trip.tripType Optional. The type of trip, revenue, non-revenue.serviceType Optional. The type of service, whether the trip is regular,

limited, express, bus rapid transit, etc.timeBegin Mandatory. Time when the trip begins.

document.docx 150


Time in seconds from midnight for the schedule day. Note that the service might begin on the day before midnight if the value is negative (i.e., -60 is 11:59 pm on the day before), or the day after if the value is greater than 24 hours (i.e., 86400 seconds is 12:00 am on the day after).

timeEnd Mandatory. Time when the trip ends.

Time in seconds from midnight for the schedule day. locationBegin Mandatory. Location where the trip begins.

The location references a locationID in the Location element.locationEnd Mandatory. Location where the trip ends.

The location references a locationID in the Location element.File Header Format for PDP_TripList.csv:

[metadata, bpm_timePeriod, tripID, routeID, patternID, dayType, tripName, tripType, serviceType, timeBegin, timeEnd, locationBegin, locationEnd]

Table 85: Service Headway TripTimeList File Description

TripTimeList File Field Name Descriptionmetadata Mandatory. File name for metadata file.tripID Mandatory. (Identifying key). A unique identifier for a trip that

was used to compute the avgServiceHeadway.routeID Mandatory. (Identifying key). A unique identifier for a route

that is associated with the trip.tripTime Mandatory. (Identifying key) Time related to the vehicle time

type at this location.

Time in seconds from midnight for the schedule day. Note that the service might begin on the day before midnight if the value is negative (i.e., -60 is 11:59 pm on the day before), or the day after if the value is greater than 24 hours (i.e., 86400 seconds is 12:00 am on the day after).

tripEventType Optional. An event that occurs at this time and place such as a passenger boarding or alighting the vehicle.

timeType Mandatory. A type of time that is measured at this location. Values include arrive, depart, pass, beginTrip or endTrip.

platformNo Optional. A platform number where the vehicle stops.locationID Mandatory. Location where the event occurs.

The location references a locationID in the Location element.seqNo Mandatory. The order in which the trip times occur in a trip.File Header Format for PDP_TripTimeList.csv:

document.docx 151


[metadata, tripID, routeID, tripTime, tripEventType, timeType, platformNo, locationID, seqNo]

12.6 Capacity DescriptionSimilar to Service Headway information, Capacity information is also collected by the ROUTE Record file. According to the NYMTC reference manual, “The average hourly capacity (person/hours) for each pattern in…a specified time period.” [9, pp., 74]

The Capacity data set, described in Section 4.1.4, under Capacity Data Set Description, describes the process and publication of capacity information. The profile for the BPM is similar, but not exactly equivalent to the general specification. The BPM requires capacity information for a time period, but the average number of persons per hour. As such, the process for generating the Capacity information is as follows:

1. For each route by agency2. For a new schedule version (or time dimension – start to end dates)

o Constrain the days to weekdays (Monday through Friday)3. For each time period

o Using the five time periods described in Table 824. Select Capacity data set

o By agencyID.o For each tripID in each routeID.o Constrain by patternID or routeDirection

5. Generate Capacity data set query6. For each designated time period, divide the resulting capacity by the number of hours in the

time period (result produces persons/hour measure)o AM_BPM Capacity = capacity / 4o MID_BPM Capacity = capacity / 6o PM_BPM Capacity = capacity / 4o EVE_BPM Capacity = capacity / 5o NT_BPM Capacity = capacity / 5

7. Collect and publish the Capacity data in two files: o PDP_Capacity_BPM.csv and o PDP_Cap_TripList_BPM.csv

8. Generate the metadata / query file for the result set.9. Bundle the Capacity and metadata file result sets in a zipped file using the following naming

convention: PDP_CAPACITY_BPM_<time-period>_<agencyAcronym>_<scheduleVersion>_<publication date>.zip

o The values in < > are parameters that represent selections made in the process steps above.

The process should be implemented in a module and saved so that BPM analysts may query the TSIP database once for the all the data they require.

document.docx 152


Table 86: Capacity File Description

Capacity File Field Name Description metadata Mandatory. File name with metadata informationbpm_timePeriod AM_BPM, MID_BPM, PM_BPM, EVE_BPM, NT_BPMsumTotalCapacity Mandatory. The summary capacity of the vehicles scheduled for

the trips during this time period. This value is divided by the number of hours in the time period.

sumWcCapacity Optional. If requested, summary data on the wheel chair capacity is included in the summary data set. This value is divided by the number of hours in the time period.

tripCount Mandatory. (checksum). The number of trips used to generate the summary capacity values.

File Header Format for PDP_Capacity.csv:[metadata, bpm_timePeriod, sumTotalCapacity, sumWcCapacity, tripCount]

Table 87: Capacity TripList File Description

TripList File Field Name Descriptionmetadata Mandatory. File name with metadata informationbpm_timePeriod AM_BPM, MID_BPM, PM_BPM, EVE_BPM, NT_BPMtripID Mandatory. (Identifying key). A unique identifier that identifies

the trip.routeID Mandatory. (Identifying key). A unique identifier that associates

the trip with the route.patternID Mandatory. (Identifying key). A unique identifier that associates

the trip with the stopping pattern.dayType Mandatory. (Identifying key). A code for the type of day. Only

weekdays are needed to generate Capacity for the BPM.totalCapacity Mandatory. The total capacity of the vehicle that is scheduled to

operate the trip. If the vehicle is a train, then it is the total capacity for all the cars in the consist.

wcCapacity Optional. If requested, this field contains the number of tie-downs available for wheel chairs in the vehicle.

carCount Optional. If a train, this value is included. It contains the number of cars in the consist.

File Header Format for PDP_Capacity_TripList.csv:[metadata, bpm_timePeriod, tripID, routeID, patternID, dayType, totalCapacity, wcCapacity, carCount]

12.7 BPM Profile Organization and DescriptionThe BPM Profile includes two types of data sets packaged in a zipped file. For each transit agency or operator, data sets may be requested that include Capacity or Headway information.

document.docx 153


12.7.1 Metadata File DescriptionThe metadata file shall include all the information that identifies the person generating the data, the data sets from which the result set is produced, the specific query and analysis that was used to produce the result set, and the date and time of publication of the result set. The file shall be published as an XML document. The schema is included in Appendix XXX.

Table 88: Metadata for BPM Profile Schema Description

Metadata File Field Name Description FormatMetadata-ID Identifier is automatically assigned by TSIP stringIdentification

publication date The date the data set was generated. datecontact-name The name of the person who generated the data

set.string

contact-organization The name of the organization of the contact person

string

contact-phone The phone number for the contact person. string (restricted to 10 characters)

contact-email The email address for the contact person. stringContent

data-scope A short description of the data set.

For example, “Weekday capacity for Long Island Bus Route N23 for Fall 2010 schedule.”

string

mode The BPM code for mode. The translation for the BPM value is shown in Table 78: Association between BPM Mode and TSIP code values.

BPM code

new-mode-1 The BPM code for new mode 1. The translation for the BPM value is shown in Table 79.

BPM code

mode-FC The BPM code for mode for fare processing. The translation for the BPM value is shown in Table 80.

BPM code

source-data The source of the data (XML file name) from which this data was extracted.

string

agency The agency for which the data is included in the data set

agencyAcronym

start date The start of the period of activation of the schedule from which this data was extracted.

date

end date The end of the period of activation of the schedule from which this data was extracted. Note: some agencies insert an end date that is over a year old. This implies that the data is still active.

date

time-period The BPM-timePeriod related to the data set. More than one time period may be specified and included in the data set.

enumerated type

document.docx 154


routes-selected a comma delimited list of all the routes selected for the

string

data-concept This refers to whether the Capacity or Srv-Hdwy data was selected and included in the query.

enumerated type

Query InformationSpatial-dimension reference (URL) to query URLTime-dimension reference (URL) to query URLPlanning-concepts reference (URL) to query URLfile-number the number of files in zipped package integerfile-names a comma delimited list of all the file names and

extensionsstring

12.7.2 File and File Bundle DescriptionTwo types of file bundles are profiled for the BPM: Srv-Hdwy and Capacity. The content of each is described in the sections below.

Service headway File Bundle DescriptionThe Service Headway File Bundle is composed of four files. The files include one metadata file and three Srv-Hdwy files (as described in Table 83, Table 84, and Table 85). The naming conventions for the bundled and individual files are as follows:

Zipped bundle: PDP_SVC-HDWY_<time-period>_<agencyAcronym>_<scheduleVersion>_<publication date>.zip

Metadata: BPM_metadata_<metadata-id>_<publication date>.xml Srv-Hdwy: PDP_Svc-Hdwy.csv TripList: PDP_TripList.csv TripTime: PDP_TripTimeList.csv

Capacity File Bundle DescriptionThe Capacity File Bundle is composed of three files. The files include one metadata file and two Capacity files (as described in Table 86 and Table 87). The naming conventions for the bundled and individual files are as follows:

Zipped bundle: PDP_Capacity_<time-period>_<agencyAcronym>_<scheduleVersion>_<publication date>.zip

Metadata: BPM_metadata_<metadata-id>_<publication date>.xml Capacity: PDP_Capacity.csv TripList: PDP_Capacity_TripList.csv

<<Questions/comments for NYMTC: do you want locations with this data? We can generate ridership in the next version once we acquire some ridership data from transit agencies.>>

document.docx 155


13 Appendix G: List of Service Information Data Sets

Data Set Description Document ReferenceAverage Load Section 4.2.3 [p., 102]Average Ridership Section 4.2.3 [p., 103]Capacity Section 4.1.4 [p., 88]Corridor Running Time Section 4.1.4 [p., 79]Effective Headway Section 4.1.4 [p., 83]Mode Section 4.1.4 [p., 76]Pattern Running Time Section 4.1.4 [p., 79]Planned Exception Section 4.1.4 [p., 94]Service Headway and Frequency Section 4.1.4 [pp., 82 and 84]Service Type Section 4.1.4 [p., 85]Span of Service Section 4.1.4 [p., 87]Transfer Service Section 4.1.4 [p., 91]Transit Facility Transfer Set Section 4.1.4 [p., 92]Transit Feature Set Section 3.1.4 (zero, one and

two-dimension data sets)Trip Transfer Section 4.1.4 [p., 91]Passenger Count Section 4.1.24.2.3 [p, ]Average Load Section 4.1.24.2.3 [p, ]Average Ridership Section 4.1.24.2.3 [p, ]PDP Comparison Result Set Section 4.4.1 [p, ]Parking Facility Section Error: Reference

source not found [p, ]Public Transit Vehicle Section 10.1 [p, ]BPM Profiles Section 12 [p, ]

Service Headway Section 12.5 [p, ] Capacity Section 12.6 [p, ]

document.docx 156


document.docx 157


document.docx 158


<<add additional diagrams from schema>>

<<add PDP schema here>>

<<add PDP metadata schema here>>

14 Appendix H: Sample Data for Service Supplied ExamplesThis sample set references the M1 Weekday Schedule, effective June 27, 2010. The sample data set (Table 89) includes trips starting from 6:42 to 9:02 in the downtown direction (first). The timepoint location is the first stop (locationID is 26fd). The first column (Location) is the trip time in clock time, the second column (Minutes) is the clock time converted to minutes from midnight. The last column (Headway) is the difference from the current time to the last time [headway=t(i)-t(i-1)]. The Average headway is estimated on the bottom of the headway column. There are twenty nine (29) values that compose the average.

Naming Conventions:

routeID = M01

patternID = M01_1 (for first direction)

tripID = M01_1_<minutes>; e.g.,

o first trip is M01_1_354;

o last trip is M01_1_ 542.

Table 89: Sample Data Set used in PDP Examples

Location (26fd) Minutes Headway5:54 3546:06 366 126:18 378 126:30 390 126:42 402 126:52 412 106:55 415 37:02 422 77:10 430 87:12 432 27:20 440 87:22 442 27:30 450 87:32 452 27:40 460 8

document.docx 159


Location (26fd) Minutes Headway7:42 462 27:48 468 67:52 472 47:56 476 48:02 482 68:04 484 28:11 491 78:12 492 18:18 498 68:22 502 48:25 505 38:32 512 78:42 522 108:52 532 109:02 542 10

AVG 6.482759n=29

document.docx 160