June 6, 2018 Supplemental Information

BOARD OF DIRECTORS JUNE 6, 2018 SUPPLEMENTAL INFORMATION

ITEM #E11 EMPLOYEE RECOGNITION AWARDS ITEM #F3 PRINTING SERVICES ITEM #F4 BUS ARRIVAL PREDICTION INFORMATION SYSTEM ITEM #F5 LANDSCAPE PROJECT – SAN BERNARDINO TRANSIT CENTER ITEM# E11 ITEM # F3

The Cubic |NextBus Solution for Real-Time Passenger Information

Standard Terms & Conditions

May 2018

Standard Terms and Conditions

Table of Contents 1 Definitions ...... 3 2 Term of the Agreement...... 3 3 Services ...... 3 4 Equipment...... 4 5 Payment ...... 4 6 Intellectual Property ...... 5 7 Indemnification ...... 5 8 Limitation of Liability ...... 6 9 Expiration/Termination ...... 6 10 Disputes ...... 6 11 Force Majeure...... 7 12 Governing Law...... 7 13 Notice...... 7 14 Waiver...... 7 15 Severability...... 7 16 Complete Agreement...... 7

Appendices

A: Service Level Agreement B: Calculation of Charges C: Cubic GTFS Specification Manual

1800 Sutter St #900, Concord, CA 94520

Page 2 of 8

Standard Terms and Conditions

1 Definitions

a. “Agreement” means this Agreement for the Provision of NextBus Equipment and Services.

b. “Cubic” means Cubic Transportation Systems, Inc.

c. “Customer” means the party entering into this Agreement with Cubic.

d. “Equipment” means any piece of hardware fielded by Cubic in performance of this Agreement that is necessary for Cubic’s performance of the Services for the benefit of a specific customer.

e. “Mobile Application” means the mobile application developed and operated by Cubic as part of the Service.

f. “Service” or “Services” means Cubic’s operation of its software on behalf of its Customers as manifested in the reports or displays resulting from the use of that software.

g. “Service Level” or “Service Levels” means the levels at which Cubic agrees to maintain and operate the Service as further detailed in Appendix A, Service Levels.

2 Term of the Agreement.

The term of this Agreement shall commence on the latter of: (i) [July 1, 2018]; or (ii) the Effective Date and expire on [June 30, 2021, with the option to extend the contract two single option years ending no later than June 30, 2023], unless earlier terminated as otherwise provided herein.

3 Services

a. Cubic shall provide the Services in a professional and workmanlike manner as contemplated in this Agreement. Customer’s sole remedy for Cubic failing to provide the Services as contemplated herein shall be any payment deductions allowed for in Exhibit A, Service Levels, as stated in b below. CUBIC EXPRESSLY DISCLAIMS ALL OTHER WARRANTIES WITH RESPECT TO THE SERVICES, EXPRESS OR IMPLIED OR STATUTORY, INCLUDING THOSE RELATED TO MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, SATISFACTORY QUALITY, ACCURACY OR COMPLETENESS OF RESULTS, CONFORMANCE WITH DESCRIPTION, NON-INFRINGEMENT, COURSE OF DEALING, OR USAGE OF TRADE.

b. Cubic shall provide the Services at the Service Levels contemplated in Exhibit A, Service Levels. Should the Services not meet the Service Levels, Customer may deduct amounts from any payment due Cubic as permitted under Exhibit A. Cubic is not liable for any failures of underlying communication carrier services including, but not limited to, 1XRTT services and the internet. From time to time, Cubic may schedule intentional downtime for system maintenance or upgrades. Cubic will strive to minimize downtime for maximum availability of the Services.

1800 Sutter St #900, Concord, CA 94520

Page 3 of 8

Standard Terms and Conditions 4 Equipment

a. As part of this Agreement, Customer may purchase Equipment from Cubic. Cubic maintains pricing for the Equipment incorporated herein as Appendix B, Calculation of Charges.

b. Customer will pay all shipping costs related to shipping the Equipment to the Customer’s facility. All risk of loss and damage to the Equipment will pass to the Customer upon the Equipment leaving Cubic’s facility. Title to the Equipment will pass to Customer when Cubic has received payment from the Customer for the Equipment. Customer shall have the right to inspect within 30 days of receipt and/or test the Equipment prior to acceptance. If upon inspection or testing the Equipment or any portion thereof are found to be nonconforming, unsatisfactory, defective, of inferior quality or workmanship, or fail to meet any requirements or specifications contained herein, then without prejudice to any other right or remedies, Customer may reject the Equipment and title and risk of loss of the nonconforming Equipment shall remain with Cubic.

c. Cubic will use commercially reasonable efforts to meet any stated delivery date(s).

d. Cubic will warrant the Equipment against defects in workmanship and material on a return-to- factory basis for a period of one (1) year from the date on which Customer receives the Equipment. Customer shall return the defective Equipment in accordance with Cubic’s shipping instructions. Cubic’s sole responsibility under this warranty shall be, at Cubic’s option, to either repair or replace, during Cubic’s normal working hours, any component which fails during the warranty period because of a defect in workmanship and material. If Cubic determines that the Equipment is not defective within the terms of the warranty, Customer shall pay Cubic all costs of handling, transportation, and repairs at Cubic’s then-prevailing rates. If Customer disputes Cubic’s determination that the Equipment is not defective both parties agree to follow the disputes provision below. CUBIC EXPRESSLY DISCLAIMS ALL OTHER WARRANTIES WITH RESPECT TO THE EQUIPMENT, EXPRESS OR IMPLIED OR STATUTORY, INCLUDING THOSE RELATED TO MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, SATISFACTORY QUALITY, ACCURACY OR COMPLETENESS OF RESULTS, CONFORMANCE WITH DESCRIPTION, NON-INFRINGEMENT, COURSE OF DEALING, OR USAGE OF TRADE.

5 Payment

a. Cubic will invoice Customer for Equipment when Customer places an order. Customer will pay the invoice within 30 days of the date the invoice was issued.

b. Cubic will invoice Customer in advance at the beginning of each month for Services to be rendered that month. Customer will pay the invoice within 30 days of the date the invoice was issued.

c. All invoices will be exclusive of all sales, use, and like taxes. Customer shall be entirely responsible for any and all taxes. If Customer has a tax exemption, it will supply appropriate tax exemption certificates to Cubic.

1800 Sutter St #900, Concord, CA 94520

Page 4 of 8

Standard Terms and Conditions 6 Intellectual Property

a. Cubic retains for itself all intellectual property rights in and to all Equipment and Services, including but not limited to any patents (pending or otherwise), copyrights, trademarks and trade secrets.

b. To the extent Customer has purchased Equipment from Cubic, Cubic hereby grants to Customer a perpetual, royalty free, non-exclusive non-transferable license to use the Equipment for its intended purpose as contemplated under this Agreement. Customer may not assign, sublicense, or otherwise transfer this license. Customer shall not, without the express written consent of Cubic, provide, disclose, transfer, or otherwise make available any Equipment to any third party. Customer shall take appropriate action by instruction, agreement, or otherwise, with those of its employees and third party agents having access to any Equipment, to restrict and control the use, copying, modification, disclosure, transfer, protection, and security of such Equipment in accordance with these Terms and Conditions. Customer agrees to protect any Equipment with the same standard of care which it uses to protect its own like products, services or proprietary information. Customer shall not reverse engineer or decompile the Equipment or any associated firmware within the Equipment. Notwithstanding anything to the contrary, Proprietary Information shall not include any information that has been disclosed pursuant to a public records request under the California Public Records Act and any other applicable sunshine laws. It shall be Cubic’s sole responsibility to protect its information from disclosure in response to a public records request made pursuant to the California Public Records Act and any other applicable sunshine laws.

7 Indemnification a. Cubic agrees to defend, or at its option settle, indemnify and hold Licensee harmless from any and all third party intellectual property infringement suits, claims, or proceedings brought against Customer as a result of Customer’s stand-alone use of the Equipment or Software where Customer has (i) given Cubic prompt notice of such suit, claim, or proceeding; (ii) allowed Cubic to have sole control of the defense or settlement of such suit, claim or proceeding; and (iii) given Cubic all necessary assistance to defend the same.

b. Notwithstanding subparagraph (a) above, Cubic shall not be bound to defend, indemnify, or hold Customer harmless where (i) such claim or action would have been avoided but for modifications of the Equipment or Services, or portions thereof, made after delivery to Customer; (ii) such claim or action would have been avoided but for the combination or use of the Equipment or Services, or portions thereof, with other products, processes or materials not supplied or specified in writing by Cubic; (iii) Customer continues such allegedly infringing activity after being notified thereof or after being informed of modifications that would have avoided the alleged infringement; or (iv) Customer’s use of the Equipment and Services is not strictly in accordance with the terms of this Agreement.

c. If a third party's claim endangers or disrupts Customer's use of the Equipment or Services, Cubic shall, at its option and at no charge to Customer, (i) obtain a license so Customer may continue use of the Equipment or Services; (ii) modify the Equipment or Services to avoid the infringement; or (iii) replace the Equipment or Services with a compatible, functionally equivalent and non-infringing product.

1800 Sutter St #900, Concord, CA 94520

Page 5 of 8

Standard Terms and Conditions d. THE FOREGOING PROVISIONS OF THIS SECTION STATE THE ENTIRE LIABILITY AND OBLIGATIONS OF CUBIC, AND THE EXCLUSIVE REMEDY OF CUSTOMER, WITH RESPECT TO ANY ACTUAL OR ALLEGED INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHTS BY THE EQUIPMENT OR SERVICES.

8 Limitation of Liability a. Except as expressly stated in Section 6, Indemnification, Cubic’s entire liability under this Agreement shall not exceed the amounts it has been paid by Customer during the twelve (12) months immediately preceding the event which gave rise to such liability.

b. IN NO EVENT WILL CUBIC BE LIABLE FOR COSTS OF PROCUREMENT OF SUBSTITUTE EQUIPMENT OR SERVICES BY CUSTOMER. IN NO EVENT SHALL CUBIC HAVE ANY LIABILITY TO THE OTHER PARTY FOR ANY LOST PROFITS OR REVENUES OR FOR ANY INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL OR PUNITIVE DAMAGES HOWEVER CAUSED, WHETHER IN CONTRACT OR TORT OR UNDER ANY OTHER THEORY OF LIABILITY, AND WHETHER OR NOT CUBIC HAS BEEN ADVISED ON THE POSSIBILITY OF SUCH DAMAGES. THE FOREGOING DISCLAIMER SHALL NOT APPLY TO THE EXTENT PROHIBITED BY APPLICABLE LAW.

9 Expiration/Termination

a. Either party may terminate this Agreement for breach of this Agreement by the other party where such breach has not been cured after having received proper notice of the breach and at least 14 days to cure.

b. Cubic may terminate this Agreement for convenience upon 60 days’ prior written notice to customer.

c. Upon expiration or termination each party shall pay the other party all monies due and owing.

10 Disputes

a. Any controversy, dispute, or claim (collectively, “Disputes”) arising out of or under this Agreement which is not timely settled by informal negotiations by the Parties shall be resolved through arbitration to take place in San Diego, California, utilizing the American Arbitration Association (“AAA”) and its Commercial Rules then in effect. Any judgment or order rendered by the arbitrator may be entered in any court of competent jurisdiction. Each Party shall be responsible for its respective costs and attorneys’ fees incurred in arbitration, except that costs and fees invoiced by the AAA for the services of the arbitrator(s) and its own fees and expenses shall be borne equally by the Parties.

b. Customer acknowledges that, due to the unique nature of the Equipment and Services, there may be no adequate remedy at law for Customer’s unauthorized use or disclosure of the Equipment or Services in breach of this Agreement and that such breach may cause immediate and irreparable harm to Cubic. Accordingly, notwithstanding the provisions of the paragraph above, upon any such breach or any threat thereof by the Customer, Cubic shall be entitled to pursue appropriate equitable or injunctive relief from any court of competent jurisdiction.

1800 Sutter St #900, Concord, CA 94520

Page 6 of 8

Standard Terms and Conditions 11 Force Majeure.

Neither party will be responsible for any failure or delay in its performance under this Agreement (except for any payment obligations) due to causes beyond its reasonable control, including, but not limited to, labor disputes, strikes, lockouts, shortages of or inability to obtain labor, energy, raw materials or supplies, war, terrorism, riot, natural disasters or governmental action.

12 Governing Law.

This Agreement shall be governed by California law, without regard to its conflict of laws provisions. The Parties waive California Civil Code Section 1654, which states "in cases of uncertainty not removed by the preceding rules, the language of a contract should be interpreted most strongly against the party who caused the uncertainty to exist."

13 Notice.

Any notice under or in connection with this Agreement shall be in writing and delivered by reputable overnight mail equivalent carrier, facsimile, or first class mail. Such notice shall be deemed to have been given when received by the party to which the communication is directed at its address set forth in the beginning of this Agreement.

14 Waiver.

The failure to exercise any right under this Agreement shall not be deemed to be a waiver of such right, and shall not affect the right to enforce each and every right hereof. The waiver of any breach of any term, provision, covenant, or condition herein contained shall not be deemed to be a waiver of any (a) subsequent breach of such term, provision, covenant, or condition or (b) other term, provision, covenant, or condition.

15 Severability.

If any material condition or provision contained herein is held to be invalid, void, or unenforceable by a final judgment of any court of competent jurisdiction, then the remaining provisions of this Agreement shall remain in full force and effect and the unenforceable provision shall be deemed modified to the limited extent required to permit its enforcement in a manner most closely representing the intention of the Parties as expressed herein.

16 Complete Agreement.

This Agreement contains the complete understanding between the parties and supersedes all prior contemporaneous communications, agreements, and understandings with respect to the subject matter herein. This Agreement may only be modified by a written amendment executed by duly authorized representatives of each party.

1800 Sutter St #900, Concord, CA 94520

Page 7 of 8

Standard Terms and Conditions

IN WITNESS WHEREOF, the below Parties have caused this Agreement to be executed by their duly authorized representatives below:

“CUSTOMER” Cubic Transportation Systems, Inc.

By: By:

Title: ______Title: ______

Signature: ______Signature: ______

Date: ______Date: ______

1800 Sutter St #900, Concord, CA 94520

Page 8 of 8

The Cubic|NextBus Solution for Real-Time Passenger Information

Appendix A, Service Level Agreement

May 2018

Service Level Agreement

Table of Contents

1.0 Introduction ...... 4 2.0 Definitions...... 4 3.0 The Cubic|NextBus System ...... 5 4.0 Cubic Hardware Maintenance Support, if applicable ...... 5 Local Hardware System Components ...... 5 AVL - GPS Equipment and Peripherals Hardware ...... 6 Passenger Information Display Devices...... 6 Maintenance Support Services: ...... 6 Parts Replacement ...... 6 Equipment Subsystem Swap ...... 7 Exclusions from Maintenance Support Services ...... 7 Customer’s Responsibilities – Hardware Maintenance ...... 7 5.0 Cubic Software as a Service (SaaS) Support Services ...... 8 SaaS Support Services ...... 8 System Administration ...... 8 On-going Monitoring of System ...... 9 Wireless Communication Monitoring ...... 9 Minor Product Enhancement Releases ...... 10 Existing Route/Stop/Schedule Changes ...... 10 Exclusions from Basic Support Services...... 11 Customer Responsibilities – SaaS Support ...... 12 6.0 Cubic Customer Support – Hardware Maintenance & SaaS Support...... 12 Cubic Customer Support Services ...... 12 Escalation Procedure ...... 13 Holidays and Special Dates Scheduling ...... 13 7.0 Cubic Privacy Policy ...... 14

1800 Sutter St #900, Concord, CA 94520

Service Level Agreement

Collection, Access, Use of Information of Current Customers ...... 14 Collection, Access and Use of Data of Former Customers ...... 15 Data Confidentiality and Security...... 15 Data Integrity Measures ...... 15

1800 Sutter St #900, Concord, CA 94520

Service Level Agreement

1.0 Introduction

This Service Level Agreement will define the terms of service as it pertains to the Cubic|NextBus platform for providing Passenger Information Systems and services that the Customer may utilize towards to operations of its transportation and/or transit systems.

2.0 Definitions

a. “Availability” means the continued access and up time of the Passenger Information Systems and the ability for Customer and passengers to make use of its functionality.

b. “AVL System” means Automatic Vehicle Location system.

c. “Global Positioning System” or “GPS” is a satellite based navigational system that allows Customer Vehicles to be tracked.

d. “GOC” means the Global Operations Center.

e. “GTFS” means General Transit Feed Specification and is a common format for public transportation schedules and associated geographic information.

f. “LED or LCD Displays” means displays located in Customer’s bus shelters and platforms that inform Passengers regarding the arrival times of Vehicles.

g. “Local Hardware” means hardware provided by Cubic to Customer that is required to provide the software services.

h. “Mobile Application” means the Cubic application components that are deployed on the mobile phone to alert Passengers to the location of specific Customer Vehicles.

i. “NextStop” means announcement of next stop.

j. “Passengers” refers to members of the public using Customer’s services.

k. “Route” means the exact travel pattern taken by each Customer Vehicle, with the same scheduled stops each time the route is travelled. Any deviation from the travel pattern or stops will be a new route.

l. “Software” means the Cubic Passenger Information Systems solution computer software components that are utilized to provide the services to Customer as part of this Agreement.

m. “Updates” means changes and bug fixes to the Software utilized by Cubic to provide the services to Customer, whether for the purpose of correcting an issue in the Software or enhancing the existing functionality of the Software.

1800 Sutter St #900, Concord, CA 94520

Service Level Agreement

n. “Upgrades” means changes to the Software utilized by Cubic to add new functionality to the Software which become available at Cubic’ catalogue price.

o. “Vehicles” means Common Carrier Vehicles owned and/or operated by the Customer and are typically available to the general public for transportation.

3.0 The Cubic|NextBus System

The Cubic|NextBus System consists of various hardware components and/or AVL data feeds that provide passenger information. The system consists of two major segments:

1) Customer Local Hardware system components that are installed on Customer’s vehicles and supply GPS information and display passenger information generated by the Cubic Servers. Local Hardware consists of two (2) subsystems:

• Automatic Vehicle Location (AVL) – GPS Hardware. • Passenger Information Display Devices.

2) Software as a Service (SaaS) that maintains and upgrades the Cubic software. Cubic SaaS typically includes the following four (4) subsystems and occasionally includes third party AVL integration:

• Internet-based map displays with local-street maps and route system overlay • Transit management reports • Real time bus arrival information for passengers • Third party schedule integration

4.0 Cubic Hardware Maintenance Support, if applicable

Title to the Hardware passes to Customer when the Hardware is paid for in full. However, Cubic bears all responsibility for loss of or damage to the Hardware during initial shipment after purchase and until Hardware is delivered to Customer, unless Customer selects its own mode of shipping. In repair case that fall under the limited warranty, risk of loss is borne by Cubic for return of the Hardware and upon return to Customer, following repair.

Local Hardware System Components

This Maintenance Agreement covers the Customer’s Local Hardware system components. For SaaS services, please refer to the SaaS Service Level (SLA) detailed

1800 Sutter St #900, Concord, CA 94520

Service Level Agreement in Section 5.0.

AVL - GPS Equipment and Peripherals Hardware

The Cubic GPS Equipment and Peripherals (the AVL) consists of the following components:

• DCU – Driver Control Unit (includes GPS receiver, wireless modem, and serial interface) • Dual GPS/Wireless antenna and cable

Passenger Information Display Devices

The GPS Equipment and Peripherals Hardware provides the prediction and message information directly to passengers through a variety of display devices such as the items below, which are covered under this Agreement:

• Outdoor Transit Displays also known as kiosks. • Platform and Shelter LED and/or LCD Displays

Maintenance Support Services:

Cubic provides Maintenance Support services necessary to ensure that each Customer is able to operate the installed Cubic systems according to the agreed specifications. The Basic Maintenance Support includes the following services for all Cubic AVL products/subsystems and displays:

• Repair and return defective or non-operational parts to Customer • Repair and return defective or non-operational Equipment Subsystem (Unit) Swap

Parts Replacement

Cubic shall provide the following services:

• Telephone support to trouble-shoot the subsystems, identify problems and provide resolution. • Supply Return Materials Authorization (RMA) to Customer to track returned hardware. • Insure the subsystem and parts returned to Cubic for repair. • Insure the shipments of repaired subsystem to customers.

1800 Sutter St #900, Concord, CA 94520

Service Level Agreement

Equipment Subsystem Swap

After working with Cubic to trouble-shoot a defective unit, if a problem is identified, Customer shall remove the unit and ship it (at Customer’s expense) to Cubic for repair. If it becomes necessary to ship replacement parts to the Customer, then Cubic will endeavor to ship a replacement unit within five (5) business days from the time the incident is reported so as to minimize downtime of the Customer’s system hardware. Occasionally a replacement part will not be available to ship within the 5-day goal. If this occurs Cubic will ship as soon as the part is available. If additional time and/or materials are required beyond shipping a replacement unit, Cubic will provide an estimate to the customer for the additional cost.

Exclusions from Maintenance Support Services

The following items are excluded from Cubic’s support services:

• Problems caused by failure of Customer’s operations staff to follow reasonable instructions or corrective procedures provided by Cubic; • hardware misuse, negligence, willful misconduct, tampering, accident, abuse, fire, flood, wind, earthquake, act of God or public enemy; • upgrade of GPS Equipment and sign hardware; • on-site trouble shooting; • on-site repair of hardware; • shipping costs for repair parts; and, • all costs associated with on-site support, including travel and living expenses as well as labor charges incurred by Cubic or Cubic’s subcontractors.

Customer is responsible for all services rendered as a result of any of the foregoing exclusions and will be invoiced on a time and material basis at Cubic’s then catalog rates unless these maintenance support services are purchased at a negotiated price at the time of contract negotiation. Cubic shall not perform any of these services without first providing Customer with a written estimate of costs for such services and obtaining Customer’s written consent.

Customer’s Responsibilities – Hardware Maintenance

Below is a list of Customer’s responsibilities:

1800 Sutter St #900, Concord, CA 94520

Service Level Agreement

• Report the issue to [email protected] • Provide a primary and secondary support contact to serve as a filter for problems reported by Customer’s end-users or operators to Cubic and as an authorized contact for Cubic support. • Provide full descriptions of issues, respond to Cubic inquiries, and otherwise assist Cubic to diagnose the problem. • Provide support to troubleshoot and fund the repair of defective hardware that is not under this maintenance contract. • Attain an RMA number from Cubic for tracking, remove and ship defective hardware to Cubic (at Customer’s sole expense), or if circumstances mandate, then; • Attain an RMA number from Cubic and a Cubic field representative will repair or replace the equipment on site. If an on-site visit is required, the Customer is responsible for Cubic’s travel and expenses to and from the site. • Customer shall pay for the cost to ship defective parts to Cubic for repair.

5.0 Cubic Software as a Service (SaaS) Support Services

SaaS Support Services

Below is a list of the services provided to Customer by Cubic to support the SaaS:

• System Administration • On-going Monitoring of System Using Automatic Alerts and Web Access • Wireless Communication Monitoring • Minor Product Enhancement Releases • Customer Support Services • Escalation Procedure (see Section 6.2 below) • Existing Route and Stop Changes • Schedule Changes • Holidays and Special Days Scheduling

System Administration

“System Administration” includes:

1800 Sutter St #900, Concord, CA 94520

Service Level Agreement

• Maintaining a private network system infrastructure for managing, storing, archiving, and protecting the Customer’s AVL and other related data. • Performing daily backups of AVL and other related data to ensure secure data storage and quick recovery for up to six (6) months. • Ensuring continuous data protection and data integrity through a secure firewall. • Maintaining software at a level of functionality that, at a minimum, meets the level of functionality established at the time that the System first enters production. • Providing ongoing remedial software support by qualified software/system engineers. Remedial software support complies with the Cubic configuration management process; software changes to the System, and testing of changes. • Maintaining system uptime with minimal interruptions that may be caused by periodic scheduled backup or other unscheduled interruptions. • Working directly with wireless carriers to resolve issues originated by the carriers.

On-going Monitoring of System

Cubic support engineers will monitor Customer’s system health by utilizing various tools via the Internet. These tools allow communication between the system and the support engineers and serve to bring more stability to the Customer’s system. This monitoring includes: • Server-to-sign and server-to-GPS Equipment communication; • Internet connectivity of servers; • Overall health of Customer’s system; and, • Review of notifications from wireless carrier when data link is affected due to network maintenance, stations power-cycled and system changes at the Cellular Radio base stations.

Wireless Communication Monitoring

The wireless data communications are provided via Cellular Radio, a public data network. Cellular Radio provides for the transmission of the location of the vehicle, current route assignment from the vehicle to the AVL server and prediction data from the server to the sign. It uses standard Internet protocols to transmit and

1800 Sutter St #900, Concord, CA 94520

Service Level Agreement receive data from mobile devices. Wireless carriers supply the Cellular Radio service and this service is provided under this Agreement. The wireless carrier contract is between the carrier and Cubic, therefore it is Cubic’s responsibility to address any service interruptions directly with the carriers. This minimizes contact requirements for the implemented systems to one phone call.

Minor Product Enhancement Releases

The SaaS includes a release service which provides software product enhancements, as they become available. All enhancements are tested on Cubic’s test servers in a controlled environment before deployment. All Customer systems will be automatically upgraded with the enhancements, after prior notification to Customers and at a scheduled time that would minimize negative impact to Customer operations.

Existing Route/Stop/Schedule Changes

Cubic services include engineering time for any route/stop/schedule change. The engineering time is calculated at up to four (4) person-hours for each existing route, each year during the life of the contract.

1) Cubic will provide Customer with a Standard Format Template in MicroSoft® Excel (Standard Template) for bulk loading of all schedules for Customers who do not utilize the General Transit Feed Specification (GTFS). GTFS Customers need to follow standard GTFS format with some enhancements documented in the Cubic GTFS Specification. Cubic may refuse to upload Customer submissions that are not provided via the proper format. GTFS submissions must also be submitted two (2) weeks prior to the planned activation date. Customers who are not utilizing the standard GTFS format must submit their template data four (4) weeks prior to the planned activation date. Should Customer request that a GTFS or non-GTFS submission be implemented on an expedited, rushed or emergency basis, meaning that Customer has requested implementation sooner than the above-referenced two (2) week, for GTFS and four (4) week, for non-GTFS submission minimum timeframe, will be assessed an expedite fee of $150.00 per hour.

2) Cubic will not conduct reconfigurations of current routes, fix erroneous submissions or provide quality assurance of Customer data which exceeds the allotted four (4) hours per route per year. Customer may seek to negotiate a change order for such error correction, quality assurance or template conversion services, however, Cubic is under no obligation to provide such services.

3) Cubic is currently developing a GTFS Editor. Once the GTFS Editor is released, the customer may: (a) utilize the GTFS Editor as a self-service tool, (b) employ Cubic to maintain their schedules or (c) seek the services of a third-party specializing in such services. Cubic will provide all GTFS Editor training material as well as a total of forty (40) hours of

1800 Sutter St #900, Concord, CA 94520

Service Level Agreement direct assistance which will cover twenty (20) hours of initial training and twenty (20) hours of tailored update help. Cubic will also provide customer support for routine requests. Should Customer require additional training or support hours, Cubic will quote these additional services on a time and materials basis.

Exclusions from Basic Support Services

SaaS Services exclude the following scope of work:

• Problems caused by failure of Customer’s operations staff to follow instructions or corrective procedures provided by Cubic; • hardware and system misuse, negligence, willful misconduct, tampering, accident, abuse, fire, flood, wind, earthquake, act of God or public enemy; • customization of the Cubic software and/or management reports designed and implemented exclusively and specifically based on Customer requirements; • support and maintenance of customization as stated in (c); • upgrade of GPS Equipment and sign hardware; • repair for hardware failures after warranty expires; • shipping costs for repair parts, including warranty repairs; • maintenance of any third party hardware or software purchased under the Purchase Contract; • implementation of route/stop/schedule changes that exceed four (4) hours per route as stated in 5.6 above; • custom interface and or code implemented exclusively based on Customer requirements; • support and maintenance for custom interfaces; • all costs associated with on-site support, including travel and living expenses as well as labor charges incurred by Cubic or Cubic’s subcontractors; and, • new features such as Connection Protection and NextStop Announcement.

Customer is responsible for all services rendered as a result of any of the foregoing exclusions and will be invoiced on a time and material basis at Cubic’s, then rates unless these support services are purchased at a negotiated price at the time of initial system implementation and Agreement negotiation or added by written Change Order. Cubic shall not perform any of these support services without first

1800 Sutter St #900, Concord, CA 94520

Service Level Agreement

providing Customer with a written estimate of costs for such services and obtaining Customer’s consent.

Customer Responsibilities – SaaS Support

Below is a list of Customer responsibilities:

• When contacting Cubic for support through the official contact mechanism of emailing [email protected] or calling 1-877- NextBus provide a full description of the present data conditions when the problem occurred and assist Cubic to diagnose the problem; • Provide all data related to route/job/schedule changes as described under Section 5.6; • Maintain third-party hardware and software purchased under the Purchase Contract; • Provide data for route/stop/schedule changes that exceed the number of changes stipulated in Section 5.6; • Provide funds for implementing route/stop/schedule changes that exceed the route/stop/schedule set forth in Section 5.6. • Agency is responsible for removing and shipping defective hardware to Cubic for repair.

6.0 Cubic Customer Support – Hardware Maintenance & SaaS Support

Cubic Customer Support Services

Cubic customer support services provides two modes for reporting problems to the Call Administrator:

(1) calling a toll-free phone number for urgent issues; and

(2) sending an email to report less urgent or low-priority issues.

Reported problems are logged and dispatched to the respective Cubic support representative. During this reporting process, the caller must provide as much information as possible about the problem, enabling the Call Administrator to efficiently identify the appropriate support engineer to respond to the call. While email communication is preferred, Customer may place the toll-free call at any time, leaving detailed problem reports on voicemail. Such calls will be responded to accordingly.

1800 Sutter St #900, Concord, CA 94520

Service Level Agreement

• Global Operations Center (GOC): 1-877-NextBus (877-639-8287) • E-mail: [email protected].

Both venues of support are available 24 hours per day, 7 days per week.

The GOC will log in all incoming calls, assign a ticket number, and provide Level 1 Support Which entails basic support and troubleshooting, such as password resets, break/fix instructions, ticket routing and escalation to Level 2 and Level 3 support. Level 2 Support entails break/fix, configuration issues, troubleshooting, software installations, hardware repair (including in-house repair or coordinating depot services). If necessary the Level 3 support, if it is out of their skill set or ability to solve. Level 3 Support involves troubleshooting, configuration, database administration, and repair for server, network, infrastructure, Data Center, email, file shares, and other infrastructure issues. Levels 2 and 3 Support are available during standard business hours, 8 am to 5 pm only.

Escalation Procedure

The GOC is the starting point for resolution and escalation. During business hours, Cubic’s escalation procedure serves as a mechanism for the Customer to attain Cubic management attention on any problem that the Customer feels is not being adequately resolved.

Holidays and Special Dates Scheduling

Schedules for holidays and other special dates on which transit service or schedules are different (Example: Using Sunday operating schedule for a holiday that falls on a Monday) must be submitted in a file format prescribed by Cubic. All revisions and updates must be submitted three (3) weeks before the actual changes become effective to the Public. As part of the services, each customer is allowed three (3) holiday schedule changes each year in addition to the allotment of configuration time. When the number of changes exceeds three (3), Customer has the option of paying for the engineering time at Cubic’s then applicable time and materials rates or applying the engineering time required against the existing route/stop/schedule change credit. Each year’s holiday schedule must be submitted to Cubic on or before November 15th of the previous year. Engineering time required for late schedules also count towards the existing change

1800 Sutter St #900, Concord, CA 94520

Service Level Agreement

7.0 Cubic Privacy Policy

The policy below does not apply to the practices of people who are not employees or subcontractors of Cubic. Cubic shall not disclose the data to any third parties that do not agree in writing to meet or exceed the provisions of this privacy policy.

Collection, Access, Use of Information of Current Customers

7.1.1 Data Collection and Storage

Cubic collects and stores a significant amount of data about the operation of vehicles within the Cubic system. That information is stored on servers owned and operated by Cubic.

7.1.2 Information Access

Access to the data is restricted by certain security measures, which include the use of username(s) and password(s) in order to gain access to the Customer-specific portion of the Cubic web site. Cubic uses industry- standard Secure Sockets Layer (“SSL”) encryption to protect data transmissions. Access to the data is restricted to authorized Cubic employees and Customer employees (consultants, etc.) who have a business need to know in order to perform their jobs and have been provided with the user name(s) and password(s). Cubic ensures that all data is stored only in encrypted form.

7.1.3 Information Use Within Cubic

Cubic uses and shares Customer data within Cubic for a variety of reasons that include the following:

• To provide data for prediction analysis and reporting • To develop and enhance Customer management tools • To maintain Customer system • To improve and develop Cubic products and services

Cubic’s Security Policy stipulates that employees cannot divulge or distribute neither Customer-specific configuration nor operational data outside of the company without the written permission from the Customer.

1800 Sutter St #900, Concord, CA 94520

Service Level Agreement

7.1.4 Information Use With Outside Parties

Cubic does not share Customer information with other customers or outside companies unless a written permission has been obtained from Customer. However, Cubic is unable to control the distribution of user- names and passwords outside of the company and cannot be responsible for access by individuals who obtain that information from another source.

Collection, Access and Use of Data of Former Customers

Our policies and practices regarding the collection and disclosure of data of former Customers are the same as those regarding the collection and disclosure of existing Customers.

Data Confidentiality and Security

Cubic is committed to preventing unauthorized access to Customer data by maintaining procedures and technology designed for this purpose. Cubic uses industry-standard security measures to protect the confidentiality and security of Customer data. Cubic takes several steps to protect Customer data including the following:

• Updating and testing Cubic technology on a regular schedule in order to improve the protection of Customer data. • Consultants and subcontractors are required to enter into confidentiality agreements that among other limitations and restraints, restricts use of data to that which is required in the prime contract with Cubic. • Limiting access to Customer data. Cubic procedures require an employee or subcontractor to have a ‘need to know’ prior to granting access to customer data. • Maintaining and following policies that support the physical security of workplaces and records.

Data Integrity Measures

Cubic ensures that Customer data is complete and accurate. Cubic has procedures and processes to update Customer data, as well as archiving old data. Cubic protects the integrity of agency data through the following measures:

• Employing a reputable hosting company to host all Cubic servers at a

1800 Sutter St #900, Concord, CA 94520

Service Level Agreement

remote location. The hosting company is equipped with up-to-date tools and reliable network, and staffed with qualified professionals that specialized in hosting services. • Maintaining daily server backups to ensure data is properly archived. • Employing firewalls and other commercially reasonable measures to prevent unauthorized entry into systems containing customer data.

1800 Sutter St #900, Concord, CA 94520

16 Appendix B - Calculation of Charges

Services Services include those listed and described in Appendix A – Service Level Agreement.

Payment

Cubic will invoice Customer for Equipment when Customer places an order. Customer will pay the invoice within 30 days of the date the invoice was issued.

Cubic will invoice Customer in advance at the beginning of each month for Services to be rendered that month. Customer will pay the invoice within 30 days of the date the invoice was issued.

All invoices will be exclusive of all sales, use, and like taxes. Customer shall be entirely responsible for any and all taxes. If Customer has a tax exemption, it will supply appropriate tax exemption certificates to Cubic. Payment schedule is negotiated 60 days before the expiration of the contract term as referenced.

Time and Materials Customer will be invoiced at Cubic’s then catalog rates for all services provided outside of the contracted service level agreement. Holiday coverage can be arranged if Customer provides Cubic with a written request for coverage at least sixty (60) days in advance. Holiday coverage will be billable at one and a half times Cubic’s then current catalog labor rates, with a minimum of eight-hour charge. Cubic’s holidays are: New Year's Day, Martin Luther King's Day, President's Day, Memorial Day, Independence Day, Labor Day, Thanksgiving Day and Day after Thanksgiving and Christmas Day. Page 1 of 2

Continued Services

NextBus Inc. April 2, 2018 1800 Sutter St #900 Concord, CA 94520 Omnitrans

Continuity of NextBus services & rates to June 30, 2023

Continued on following page.

Page 2 of 2

Continued Services

NextBus Inc. April 2, 2018 1800 Sutter St #900 Concord, CA 94520 Omnitrans

Continuity of NextBus services & rates to June 30, 2023

End of document.

Cubic|NextBus GTFS Manual Submitting GTFS for Cubic|NextBus

December 2017 Cubic Transportation Systems, Inc. 1. Table of Contents 1. Introduction ...... 2 a. What is GTFS? ...... 2 b. How does NextBus use GTFS? ...... 2 2. General Requirements for Submission to NextBus ...... 4 a. Which GTFS Feed Files Does NextBus Need? ...... 4 b. NextBus Submissions Checklist ...... 6 3. NextBus Field Definitions ...... 7 a. agency.txt ...... 7 b. calendar.txt ...... 7 c. calendar_dates.txt ...... 8 d. frequencies.txt ...... 8 e. routes.txt ...... 9 f. shapes.txt ...... 10 i. stops.txt ...... 13 j. stop_times.txt ...... 14 k. trips.txt ...... 16 4. How Our GTFS Files Interact With One Another ...... 17 5. NextBus GTFS Best Practices ...... 18 a. General Practices ...... 18 b. stops.txt ...... 18 c. stop_times.txt ...... 18 d. trips.txt ...... 19 e. routes.txt ...... 19

2. Introduction

The Cubic|NextBus GTFS Manual is meant as an addendum to Google’s GTFS Specification requirements, which are found here: https://developers.google.com/transit/gtfs/reference, and which will be referred to later in this manual. This manual is also intended as a guide to which fields we require, and will provide additional details regarding which values affect NextBus’s interpretation of your data. This manual will also explain some of the differences between Google’s GTFS requirements versus NextBus’s GTFS requirements. We have created this document to help NextBus optimally import and interpret your GTFS data.

a. What is GTFS?

GTFS was originally designed by Google as a common format for public transit agencies to publish their data on Google’s Trip Planner. Many agencies have adopted the General Transit Feed Specification (GTFS) as their standard for sharing agency data.

A GTFS feed is a collection of at least six, and up to thirteen, .txt files contained within a .zip file and coded in UTF-8 format. Together, these files detail a transit agency’s scheduled operations as shown to a rider, and provide trip planning functionality. The files also can be used to provide analysis of levels of service (LOS) and other general performance measures. GTFS only includes scheduled operations meant to be distributed to riders; however, real-time information can be linked to GTFS schedules as an extension per related GTFS-Realtime specifications1 (Google Developers 2016).

How does NextBus use GTFS?

NextBus can process GTFS data to configure a transit system for real-time passenger information services. As GTFS is a standard for sharing agency data, we only require a subset of seven specific files with some mandatory fields included in the specification. Some of the fields that are mandatory for NextBus are defined as optional under the general GTFS requirements.

1 Google Developers. GTFS Status Overview. July 26, 2016. https://developers.google.com/transit/gtfs/ (accessed October 13, 2017).

These additional requirements help NextBus generate predictions and optimize NextBus-specific features. Below is a high-level overview of how our files interact with NextBus software:

4. General Requirements for Submission to NextBus

a. Which GTFS Feed Files Does NextBus Need?

There are some differences between the GTFS files that Google specifications require versus the GTFS files that NextBus requires. Please see the list below2:

Required by GTFS Filename What the GTFS File Defines Additional NextBus Requirements NextBus? Gives information about the transit Only one transit agency’s feed in the agency.txt Yes agency that provides the data feed agency.txt file. Specifies when services start and end, as We prefer the start_date and the calendar.txt Yes well as the days of the week when each end_date to be the same for all service is available. service_ids.

Only ONE service record defined per day of the week. That is, Mon-Fri defined as a service, but then do not also define another service for Mondays and Wednesdays only.

Defines dates that have exceptions to the Only include exceptions for the calendar_dates.txt Yes regular service(s) for the service_ids service_id. defined in the calendar.txt file. Fare information for a transit fare_attributes.txt No organization's routes. Rules for applying fare information for a fare_rules.txt No transit organization's routes. Supplies headway (time between trips) Plan to use soon, but not yet frequencies.txt No for routes with variable frequency of processed. service. Defines transit routes. A route is a group routes.txt Yes Only alphanumeric for route-id of trips that are displayed to riders. NextBus can use the route-id or route_short_name for the public- facing route name.

2 Google Developers. General Transit Feed Specification Reference. October 5, 2017. https://developers.google.com/transit/gtfs/reference/#FileRequirements (accessed October 13, 2017).

Each shape is coded in GTFS as a series of shapepoints with a latitude and a The shapes must be defined in a way longitude. These shapepoints are plotted so as to connect to the stops. This is shapes.txt Yes in order to represent the path of the because NextBus predicts arrival at vehicle(s) traveling along a single route. stops based on a vehicle’s travel The order of the shapepoints defines the along the shapes. path of the route. Times when a vehicle arrives at and stop_times.txt Yes departs from individual stops for each At least 2 stops per trip. trip. We prefer for the agency to fill in the

timepoint field. We need times for the start and end of

each trip, as does Google.

Stop_code if the agency wants to use Identifies locations where vehicles pick stops.txt Yes SMS. Stop_lat and stop_lon to at up or drop off passengers. least five decimal places, six at most.

Rules for making connections at transfer transfers.txt No points between routes. Trips for each service. A trip is a Require trip_headsign, block_id, trips.txt Yes sequence of two or more stops that shape_id. occurs at specific time.

b. NextBus Submissions Checklist

For each file, ensure that the filename complies with GTFS exactly. No approximations, no capitalizations, no other creative human variations of names. These are not supported by GTFS. For each file, check that the fields labeled as ‘Required’ in the following pages are included and spelled exactly as defined in GTFS, and populated for all columns. If any data fields or cells are missing or blank, the agency must provide them for NextBus to process the update. All files must be saved as comma-delimited text. The first line of each file must contain field names. All field names are case-sensitive Field values may not contain tabs, carriage returns, or new lines. Please check that the field names comply with GTFS standards exactly. Please do not use dashes (‘-‘) in the route_id or service_id fields. Field values that contain quotation marks or commas must be enclosed with quotation marks. Field values must not contain HTML tags, comments or escape sequences. Zip files and submit to NextBus.

• Each subsection of the Field Definitions section corresponds to one of the files in a transit feed, and lists the field names you may use in that file. • For more information on the CSV file format, see http://tools.ietf.org/html/rfc4180/. The following example demonstrates how a field value would appear in a comma-delimited file: • Original field value: Contains “quotes”, commas and text • Field value in CSV file: “Contains “”quotes””, commas and text”

5. NextBus Field Definitions

a. agency.txt

Please follow Google GTFS specifications, except in one regard: we can only process data for one agency at a time.

b. calendar.txt

The calendar.txt file is required for NextBus.

Field Name R

service_id R

Monday R Tuesday R Wednesday R Thursday R Friday R Saturday R Sunday R start_date R end_date R

• All records in calendar.txt need to have the same start_date and end_date for NextBus. That is, a weekday, sat, and sun; or a weekday and weekend, service should all start on the same day and end on the same day.

• NextBus can only process one schedule at a time, so we require the defined service dates for this GTFS schedule to match the start/end dates. Exceptions to the default service should be handled in calendar_dates.txt, and the service_id’s should not be defined here since they are defined for a particular date(s).

• Only one service record should be defined per day of the week. There can be a MoTuWeThFr service running from Monday through Friday, but there cannot also be another service defined to run on Wednesdays only (for example). This would create overlapping services schedules.

• As with Google’s GTFS, NextBus service_ids cannot have spaces within them.

c. calendar_dates.txt

The calendar_dates.txt file is optional for NextBus. IF present, it should list special service substitutions, known as exceptions, by date. Specifying hundreds of adds and drops for many to all of the dates in the schedule is discouraged.3

Field Name Required? Details service_id Required Referenced by trips.txt. This field defines specific dates for which to add or drop Date Required specific services. The exception_type indicates whether service is available on the date specified. 1 means that service is added for the specific date. 2 means that service is dropped. So, for example, if July 4 falls on a Monday and will have Sunday service, and the regular services are MoTuWeThFr, Sat, and Sun, there would be two exception_type Required entries for July 4. One entry would be for service MoTuWeThFr, and would specify 2 to drop the usual weekday service for July 4. The other entry would be for service Sun and would specify 1 to add the Sunday service specifically for July 4.

• If a “special” service or “no_service” service is desired, it should be added as an override in the calendar_dates.txt file. Like all service_ids records, it is not necessary for the service_id to be defined in the calendar.txt file.

d. frequencies.txt

This file is optional at this time.

3 GTFS Best Practices Working Group. GTFS Best Practices. http://gtfs.org/best-practices/ (accessed October 12, 2017). 8

e. routes.txt

This file is required.

Field Name Required? Details A route_id is an internal ID that uniquely defines a route, and is dataset-unique. Only one route_id should be configured per route_id Required route. Route_ids cannot have leading zeros, asterisks, underscores, or dashes. Route_ids can be shown to the public if desired. agency_id Optional Optional, The route_short_name can be used as the route number or name route_short_name but… to be shown to the public, if desired. route_long_name Optional route_desc Optional route_type Required route_url Optional Optional, Ex: FFFFFF, which is hexadecimal code for the color white. route_color but… The agency needs to set these colors. Optional, Ex: 000000, which is hexadecimal code for the color black. The route_text_color but… agency needs to set these colors.

• As with Google, there are several different route_types: 0 - tram, streetcar or lightrail; 1 - subway or metro; 2 - intercity rail or long-distance travel; 3 - bus; 4 - ferry; 5 - cable car; 6 - gondola or suspended cable car; 7 - funicular, designed for steep inclines.4

• The name of the route in the stop selector on the public-facing nextbus.com website can be configured using a route_id which generally have route numbers such as: 1, 35, 24 while if an agency rather use the short_name: Central Campus, Hill apartment, Night Owl

4 Google Developers. General Transit Feed Specification Reference. https://developers.google.com/transit/gtfs/reference/#term-definitions/ (accessed November 17, 2017) 9

f. shapes.txt

For NextBus, this file is required.

Field Name Required? Details shape_id Required Contains an ID that uniquely identifies a shape. Coordinates need to be in WGS-84 format and precise to at shape_pt_lat Required least five decimal places (ex: 30.40180). Coordinates need to be in WGS-84 format and precise to at shape_pt_lon Required least five decimal places (ex: ,-97.74855). Sequences need to be in the order of the vehicle’s arrival to that point (ie: the vehicle arrives first at shapepoint 1, then 2, etc.). Shape_pt_sequence values must be non-negative shape_pt_sequence Required integers, and must increase as the trip progresses. Optional, shape_dist_traveled but.. Please include it if you have it.

• In GTFS, a shape is defined by its points. Therefore, shapes are a sequence of points that trace the physical path that a vehicle takes along a route. For NextBus, the shapes.txt file needs to trace the actual path that the vehicle follows along the route as closely as possible. Furthermore, as our predictor is based upon predicted arrival at a given stop, the shape needs to incorporate the stops in order of expected arrival.

• For best results, when creating the shapes, please also place a coordinate at each of the stops for the route. Our shapes need to connect to the stops, as predictions are generated per stop. Connecting the shape directly to the stops helps us match the coordinates of the shape with the stops.

• While the shape_dist_traveled field is optional, we prefer that an agency fill this field in, as it helps ensure better quality shapes for the routes they represent.

• Shapepoints also need to connect to one another. When placing coordinates down a straight road, it helps if you can include at least one additional coordinate other than the start and the end. When in doubt, it is better to include more shapepoints than less.

• Unlike Google, we prefer that agencies not code the route down the centerline. The NextBus Predictor needs to connect the shape to the stops, and so, when the route is coded down the centerline, the shape will often abruptly connect from a shapepoint to a stop as shown below:

• We instead prefer the shape to match the path the bus will travel down the two sides of the road as closely as possible to ensure better quality predictions and an improved aesthetic. An example is shown in the image below:

• Shape generalization for NextBus happens when a street, road, highway, etc., is represented as a straight line, regardless of whether or not the path of travel bends. Here is an example of shape generalization:

• In this example, the route the vehicle is supposed to travel should follow Highway 215, but Highway 215 has a bend at this point. Naturally, the vehicle will follow that bend, but rather than following the vehicle’s path of travel, the shape is coded in GTFS as a straight line. This results in unpredictability due to spatial mismatch. The red arrows in the image below show the amount of unpredictability due to spatial mismatch that was registered by NextBus’s AVL Heatmap over a 24-hour period for this section:

For buses to remain predictable, the shape needs to trace the bus’s actual path of travel, and not be generalized as a straight line.

i. stops.txt

Field Name Required? Details stop_id Required

Optional, This field can supply the phone code for getting stop_code but… predictions by SMS (ie: text-messaging). stop_name Optional If not provided, we use the stop_id for the name stop_desc Optional Some agencies supply this instead of the name Coordinates need to be in WGS-84 format, and precise stop_lat Required to at least five decimal places. Coordinates need to be in WGS-84 format, and precise stop_lon Required to at least five decimal places. zone_id Optional stop_url Optional location_type Optional parent_station Optional stop_timezone Optional wheelchair_boarding Optional

For the NextBus SMS Feature (USA only):

The stop_code is required for NextBus SMS, if the agency chooses to use this feature. If the agency does not choose to use the NextBus SMS feature, then the stop_code is not required.

For NextStop:

The stop_code field is required for NextBus’s NextStop feature if the agency needs riders to access predictions using a unique code for each stop via SMS, IVR/Phone system, or web or mobile applications.

j. stop_times.txt

Field Name Required? Details trip_id Required The trip_id as defined in trips.txt Required for scheduled stops, but should be blank for arrival_time Required non-scheduled stops Required for scheduled stops, but should be blank for departure_time Required non-scheduled stops. stop_id Required The stop_id as defined in stops.txt stop_sequence Required Optional, It can be used as the trip_headsign if the agency doesn't stop_headsign but… have trip headsigns. pickup_type Optional The default is 0 for a regularly-scheduled pickup drop_off_type Optional The default is 0 for a regularly-scheduled dropoff shape_dist_traveled Optional We prefer for an agency to fill this in. Optional, Timepoint but… We prefer for an agency to fill this in.

• As with Google, NextBus requires times at the start and end of each trip.

• We prefer for agencies to use the timepoint field to indicate which stops are scheduled stops. When the timepoint flag is used, records marked as ‘1,’ or true, will be marked as scheduled points. Even if a stop is not marked as a timepoint, NextBus will still calculate and display a prediction for the stop. Generally, only major or publicly scheduled stops should be marked as a timepoint.

• We ask agencies to adhere to Google’s instructions to not interpolate the arrival_time and departure_time of every stop. Having a lot of interpolated stop_times tends to make the stop_times.txt file very cumbersome, and may result in stop_times getting dropped (aside from the start and end of the trip). For optimum results, it’s better for an agency to only include arrival and departure times for their scheduled stops, and best for an agency to use the timepoint field as well.

• NextBus will always assume that the last stop at the end of a trip is an arrival, and will set the departure of the next trip as a SchedPoint, TimePoint, or BreakPoint, depending on the bus’s dwell time before the next departure.

• Agencies can hide stops by setting both pickup_type and dropoff_type to 1. Stops are hidden if the stop does not provide public service. Some agencies define all their trips' first stops as

pickup-only and last stops as dropoff-only. This doesn't interfere with Nextbus configuring.

• When an agency defines an arrival time for a stop with a dropoff-only record followed by a departure time for the same stop with a pickup-only record, we will configure a “ NextBus timepoint” stop using that departure time. This applies to the NextBus meaning of timepoint, that is, the driver waits until the scheduled departure time before leaving regardless of when arrived. This is in contrast to a GTFS Timepoint where the vehicle is scheduled or estimated to arrive/depart at a particular stop but variations are allowed. An example of a “NextBus Timepoint” would be a mid terminal route stop at say a shopping mall where the vehicle will specifically wait until 2:00 PM to leave

• Using the agency’s use of the stop_times fields, NextBus will assign a stop condition to each stop to describe the type of stop. The stop conditions are as follows:

Stop Condition Description Generates predictions, but will not show up in reports. None Most stops in urban areas will have this condition. No public service (such as a bus depot or a non-service Hidden turnaround) Arrival and departure times are required. A scheduled SchedPoint stop will show up as a data point in reports. This is usually the stop at the end of the trip. Here, the vehicle arrives and will drop off passengers, but will not SchedArrival pick up any passengers (until the start of the next trip, or the start of the trip on the next day, etc.). NextBus Vehicle will lay over or dwell at this stop until the Timepoint departure_time

k. trips.txt

Field Name Required? Description route_id Required The route_id as defined in routes.txt service_id Required The service_id as defined in calendar.txt Shorter trip_id's are preferred, as the trip_id appears in Required trip_id many of our agency reports. We need some descriptive text for the destination of trips (ex: "to Market St., from Golden Gate Park", or Required "to Golden Gate Park, from Market St.", for a vehicle traveling between Market Street and Golden Gate Park trip_headsign in San Francisco) trip_short_name Optional The direction_id is a binary value that indicates the direction of travel for a trip. It is coded as '0' or '1,' Required where '0' is outbound and '1' is inbound, and is used to distinguish between the outbound versus the inbound direction_id trip for a route. Blocks are the sequences of trips that a single vehicle Required block_id makes. These are sometimes referred to as jobs. The shape_id as defined in the shapes.txt file. The shape_id defines the path that each trip takes as a Required sequenced list of geographical coordinates (also known shape_id as geocoordinates). wheelchair_accessible Optional bikes_allowed Optional

• If a route is a loop, then we can just assume that the direction_id should be ‘0’ for all trips. Otherwise, use ‘0’ for outbound and ‘1’ for outbound for the direction_id.

• A few key differences from Google’s GTFS for the trips.txt file: o We require the block_id field. This is not optional for NextBus. o We require the shape_id field. This too is not optional for NextBus.

6. How Our GTFS Files Interact With One Another

In general, GTFS consists of several CSV-formatted text files that are synced with one another using some common fields. In the case of NextBus, this works as follows:

The route_id field from the routes.txt file is used to link the routes.txt file with the trips.txt file.

The service_id field from the calendar.txt file is used to link the calendar.txt file with the calendar_dates.txt and trips.txt files.

The shape_id field from the shapes.txt file is used to link the shapes.txt file with the trips.txt file.

The stop_id field from the stops.txt file is used to link the stops.txt file with the stop_times.txt file.

The trip_id field from the trips.txt file is used to link the trips.txt file with the stop_times.txt file.

8. NextBus GTFS Best Practices

These are slightly adapted from the standard GTFS Best Practices5 to meet NextBus needs.

a. General Practices • GTFS data is published in iterations so that a single file at a stable location always contains the latest official description of service for a transit agency.

• Maintain the same identifiers for the stop_id, route_id, and agency_id fields across GTFS updates whenever possible.

• Remove old services (expired calendars) from the feed.

• Avoid use of abbreviations throughout the feed for names and other text unless a location is called by its abbreviated name (ie: “JFK Airport”). Abbreviations may be problematic for accessibility by screen reader software and voice user interfaces.

b. stops.txt • Stops that are in different physical locations should have different stop_id’s, even if near each other.

• Stop_id is an internal ID that is not intended to be shown to passengers.

• Maintain consistent stop_id’s for the same stops across data iterations.

• The stop_name, if used, should match the agency’s public name for the stop. It should not contain redundant words like ‘station’ or ‘stop’ unless part of the name (ie: Central Station, Union Station), or unless the stop_name is too generic (such as if it is the name of the city).

• Stop_lat, stop_lon should have a margin of error of no more than four meters when compared to the actual stop position. This equates to at least 5 degrees of precision.

c. stop_times.txt • The timepoint field should be provided. It specifies which stop_times the operator will attempt to adhere to (timepoint=1), and which other stop_times are estimates (timepoint=0).

5 GTFS Best Practices Working Group. GTFS Best Practices. http://gtfs.org/best-practices/ (accessed October 12, 2017). 18

d. trips.txt • If trips on a route service opposite directions, distinguish these groups of trips with the direction_id field, using ‘0’ for Outbound and ‘1’ for Inbound.

• The block_id must be provided.

e. routes.txt • The agency_id field should be included if it is defined in the agency.txt file.

• The route_short_name, if included, should be the commonly-known passenger name of the service, and should be no longer than 12 characters.

• The route_long_name is generally more descriptive.