REQUEST FOR PROPOSALS
#R166592
Scheduling Software
RFP Release
August 5
, 2024
Proposal Submittal
Post bid responses to PlanetBids before
September 3, 2024, at 5:00 p.m.
ATTACHMENT 1
Summary
Santa Rosa CityBus and Petaluma Transit (AGENCIES) are issuing a request for proposals for fixed route scheduling software. Responses to this RFP will allow the AGENCIES to negotiate and contract with the vendor whose proposal best meets the needs of the AGENCIES.
Important Dates
Date Issued: August 5, 2024
Deadline for Questions/Clarifications: August 14, 2024
Answers to Questions/Clarifications Posted: August 21, 2024 RFP Response Deadline: September 3, 2024
Organizational Overview
Santa Rosa CityBus
Santa Rosa CityBus is a small operator in the San Francisco Bay Area offering fixed route transit, deviated fixed route transit, and ADA Paratransit Service. The current service runs seven days a week with fourteen (14) fixed routes and one (1) deviated fixed route. The CityBus fleet is twenty-eight (28) vehicles with a current peak pull out of eighteen (18) vehicles. CityBus has a single staff member who creates the timetables, blocks, runs, and rosters. Staff currently uses The Schedule Master software for scheduling, runcutting, and rostering. GMV Syncromatics provides CityBus with its CAD/AVL services. Two to three road supervisors handle daily operations e.g. assigning extra work, assigning buses, and filling call offs.
Petaluma Transit
The City of Petaluma, Public Works Department, Transit Division manages Petaluma Transit, which provides over 400,000 transit rides throughout the City of Petaluma each year. The City of Petaluma has a population of 60,000 people.
The City of Petaluma/Petaluma Transit owns and operates a 23-vehicle system (14 fixed route and 11 paratransit vehicles). The service is operated and maintained through a third-party contract with MV Transportation, Inc. Petaluma City staff do the majority of route and operations planning for the Petaluma Transit system. The peak fixed-route bus pull for Petaluma Transit is 10 vehicles. Petaluma Transit operates all of its vehicles from its garage located at 555 N. McDowell Blvd in Petaluma. The City operates, plans and maintains six primary transit routes (with six, limited-service school trip oriented routes).
Petaluma Transit is currently using GMV/Syncromatics as its CAD/AVL provider and will be doing so for several years going forward. The City doesn’t currently have any existing route planning software and hasn’t previously had any such system previously.
Petaluma Paratransit is a dial-a-ride service and is scheduled using Trapeze PASS. Trips can be reserved for Paratransit travel up to seven days in advance, but at least one day in advance.
Petaluma Transit has four administrative staff including one Planner I/II position who is the primary person who creates bus schedules and performs runcutting. IT personnel oversee and support the collection, storage, transmittal and manipulation of data. The City’s IT department is required to support the entire IT infrastructure.
Agency Objectives
The AGENCIES hope to fulfill the following objectives by procuring scheduling software. • To enhance the efficiency and accuracy of our fixed route transit scheduling process. • To improve the quality of service we provide to passengers by optimizing routes and schedules. • To integrate real-time data and passenger information systems to more easily visualize where changes to the schedule should occur.
• To easily integrate work rules for drivers to ensure we can consistently and accurately implement all parts of our labor agreements.
• To provide exportable scheduling documents and tables for planning purposes • To maximize the effectiveness and efficiency of staff with service scheduling efforts Scope of Work
The winning vendor will be responsible for the following:
• Providing a fixed route scheduling software solution that meets the technical and functional requirements outlined in this RFP .
• To provide runcutting software for the AGENCIES fixed route services. • Customizing and configuring the software to align with AGENCIES’ specific transit operations and requirements related to labor work rules specific to the agency, local laws, State laws, and Federal laws.
• Integrating the software with existing systems and data sources, including but not limited to, real-time data feeds, GIS data, current GTFS data, and passenger information systems where applicable.
• Provide training and support for AGENCIES’ staff during the implementation and post- implementation phases. This includes providing electronic files or web-based training materials and guides.
Technical and Functional Requirements
The fixed route scheduling software should include, but is not limited to, the following technical specifications. These specifications apply to both transit operators unless specifically noted otherwise. • The ability work in a browser-based environment. Bidder will be responsible for the servers and software. The system shall create a backup every night. The availability of the program, server, application, and all the features need to be functional 99.9 percent of the time. Any major maintenance should be noticed to the AGENCIES at least 24 hours in advance if said maintenance will cause service disruptions longer than 12 hours. • The ability to have multiple windows open of the same scheduling project e.g. a window showing blocking and another showing the service schedule. • The ability to integrate work rules as defined by AGENCIES’ labor agreements and create flags when and if those rules are broken during the entirety of the scheduling process. • The ability to create visualizations of the trips in the blocking phase of scheduling service. • The ability to present a scheduler with optimization suggestions through AI or proprietary algorithms.
• The ability to export public facing schedules in both Excel and/or PDF formats. • The ability to export driver run books/paddles in both Microsoft Word and PDF formats. Bidders must provide example runbooks/paddles as part of their response. • The ability to import current GTFS data to set a base line of service including but not limited to stop locations, route alignments, and current schedule. • The ability to maintain a database of bus stops in the system including the ability to assign attributes to each stop e.g. stop has a bench, stop has a shelter, etc. • The ability to maintain a database of bus types and create block assignments based on bus types.
• The ability to produce analytics that should at the very least include revenue hours by route, total service hours by route, revenue miles by route, total miles by route, pure behind the wheel time for drivers (in service driving and deadhead, not inclusive of layovers), and trip counts by route.
• A daily operations module that gives operations staff the ability to track work assignments, hours worked by employees, bus assignments, and employee availability. Software shall track vacations, illnesses, or any definable reason that an employee is not available to work. Software shall produce lists of available bus operators to fill vacant runs. • The ability to monitor a driver’s behind the wheel time based on roster and run information as it relates to the rules for maximum driving time for passenger carrying vehicles. There should be flags for when a driver is near or will break a drive time rule based on their scheduled work. • The ability to schedule non-revenue service e.g. shuttle vehicles. • The ability to easily create schedules for routes for each day of the week e.g. specific trippers for each day of the week.
• Ability to export schedule data that is compatible with GMV Syncromatics’s CAD/AVL platform. (GMV ingests GTFS data).
• The ability to export GTFS data that meets the GTFS requirements set forth by 511. See Exhibit 5 – 511 GTFS Requirements
• The ability to set roster rules, constraints, and optimization including but not limited to service familiarity (veteran vs new drivers), specific day off patterns, guaranteed work time, levels of overtime, rest time between shifts, and specific to Santa Rosa CityBus the ability to ensure rosters either comprise of AM runs or PM runs for the work week not a combination of both in a single roster.
• Ability to auto-save, automatically recover, and manually recover prior data and schedules. This should include an archive functionality directly available to the user. • Security measures to protect sensitive data.
Implementation Plan
AGENCIES expect that the winning bidder will provide a fully functional scheduling platform within 60 days after the execution of the contract.
Bidders will provide separate timelines for implementation for both AGENCIES. The timeline should incorporate at a minimum: key milestones (including specific deliverables and associated billings at each milestone), and any dependencies within the control of the AGENCIES that are part of the scope but may extend the timeline.
Bidders will provide a thorough description of the implementation approach, which should include, but is not limited to data migration, testing, and training.
Bidders will provide a post-implementation plan for support and maintenance which outlines how support cases are handled, primary points of contact for questions and concerns about the product and billing, when routine maintenance is completed on the product, future product enhancements (provide associated costs if any), and how requests for new product components are handled.
It is the expectation of the AGENCIES that the winning bidder will provide a weekly status update until the scheduling platform is fully functional. The update can be given verbally or by email.
Vendor Qualifications and References
Please provide one example of an agency who upon using your product saw improved service efficiencies.
Please provide three other agency contacts (name and contact information) at agencies of comparable size (if possible) as references that use your product.
Provide a complete list of existing customer agency names currently using the system. Contact information for these agencies is not required.
Inquiries or Questions and/or Requests for Clarification All individuals or firms interested in submitting an RFP must address any questions or requests for clarification of the RFP via the PlanetBids website under the question-and-answer tab no later than 5:00PM on Wednesday, August 14, 2024. The City will distribute any responses to questions posed during the open period per the schedule. If responses result in a change to the RFP , the City will make those changes in the form of a formal or informal addendum to the RFP . The City will distribute the addendum through PlanetBids ONLY .
Proposal Submission Guidelines
Vendors shall submit Proposals shall be submitted electronically via PlanetBids ONLY.
Vendors should have a fully functioning scheduling platform. Companies should not submit proposals for products that are in beta or are not fully functional at the time the proposals are due. Bidders should also not submit content for products outside the scope of this RFP .
The cost proposal should reflect costs for a five (5) year term with two (2) option years. Bidders should price each year separately and indicate their pricing methodology e.g. total fleet size, active fleet, staff size, etc. If the product being proposed is modular in nature, please indicate the costs for each module summing to a total cost for each year of the contract. Cost proposals should be formatted with line items for each contract year and for each agency. Example below:
Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7
Annual Software
(Modules broken out)
Annual Maintenance,
Hosting, and Support
Training (Year 1
should have a fixed
price for onboarding
training with
following years as an
hourly rate for
refresher training)
Evaluation Criteria
Proposals will be evaluated based on compliance with technical requirements, implementation approach and expertise, and reasonableness of total price. The weighting for each score is as such:
• Compliance with technical requirements – 50%
• Implementation Approach and Expertise – 30%
• Reasonableness of Total Price – 20%
AGENCIES will select the top three scoring bidders to move forward into a practical demonstration round. Bidders will be expected to demonstrate the full functionality of their product from the beginning to the end of the scheduling process.
Terms and Conditions
The City of Santa Rosa and City of Petaluma will enter into separate contracts with the awarded proposer.
City of Santa Rosa
The winning bidder for one or both platforms will be expected to enter into an agreement per the terms of the City’s standard agreement. The contractual obligations for the vendor will be the deliverables as indicated in their proposal and their associated costs. The standard agreement is provided with the RFP for reference as Exhibit 1. The winning bidder will also be expected to meet the City’s insurance requirements in Exhibit 2 (This will be Attachment One in the actual agreement).
Petaluma Transit
The winning bidder will be expected to enter into an agreement per the terms of the City’s standard agreement. Per the deliverables provided by the vendor through the RFP process, a final scope of work document will be created for inclusion in the Professional Service Agreement. The standard agreement is provided with the RFP for reference as Exhibit 3. The winning bidder will also be expected to meet the City’s insurance requirements in Exhibit 4.
PROTEST PROCESS
Any and all protests must be in writing and must comply with the timelines and procedures set forth below:
PROTEST PROCEDURES:
Proposers may file a “protest” to an RFP with the City’s Purchasing Department via email to Purchasing Agent Brandalyn Tramel, [email protected]
. For a protest to be considered valid, the protest must:
1. Be filed in writing within five (5) business days of the RFP issue date. A second protest period is allowed for the issuance of the Agreement. Protests for this period must be received in writing on or before 5:00 p.m. of the third business day following the posting of Bid Results/Notice of Intent to Award;
2. Clearly identify the specific irregularity or accusation;
3. Clearly identify the specific City staff determination or recommendation being protested;
4. Specify, in detail, the grounds of the protest and the facts supporting the protest; and
5. Include all relevant, supporting documentation with the protest at time of filing.
If the protest does not comply with each of these requirements, it will be rejected as invalid. If the protest is valid, the City’s Purchasing Agent shall review the basis of the protest and all relevant information. The Purchasing Agent will provide a written decision to the protestor within ten (10) business days from receipt of protest. The decision from the Purchasing Agent, or his/her designee, is final and no further appeals will be considered.
Professional Services Agreement
Form approved by the City Attorney 5-11-20
CITY OF SANTA ROSA
PROFESSIONAL SERVICES AGREEMENT
WITH [NAME OF CONSULTANT]
AGREEMENT NUMBER _________
This "Agreement" is made as of this ____day of_______________, 2024 [leave date blank until all parties have signed or until Council approves], by and between the City of Santa Rosa, a municipal corporation ("City"), and [ add consultant’s full name, for example, "XYZ Sales Corporation" or "ABC Consulting, LLC" or "ABC Enterprises, LP" or "John Smith, dba Smith Consulting"] , a [add type of legal entity and state of entity formation or incorporation, for example, a "California Corporation" or a "Delaware Limited Liability Company " or a "Nevada Limited Partnership" or a " sole proprietor "] ("Consultant").
R E C I T A L S
A. City desires to [enter brief description of the task or project that is intended to be completed through this Agreement].
B. City desires to retain a qualified firm to conduct the services described above in accordance with the Scope of Services as more particularly set forth in Exhibit A to the Agreement.
C. Consultant represents to City that it is a firm composed of highly trained professionals and is fully qualified to conduct the services described above and render advice to City in connection with said services.
D. The parties have negotiated upon the terms pursuant to which Consultant will provide such services and have reduced such terms to writing.
AGREEMENT
NOW, THEREFORE, City and Consultant agree as follows:
1. SCOPE OF SERVICES
Consultant shall provide to City the services described in Exhibit A ("Scope of Services") [attach either City’s description of the services to be provided or C onsultant’s proposal and mark as Exhibit A]. Consultant shall provide these services at the time, place, and in the manner specified in Exhibit A. Exhibit A is attached hereto for the purpose of defining the manner and scope of services to be provided by Consultant and is not intended to, and shall not be construed so as to, modify or expand the terms, conditions or provisions contained in this Agreement. In the event of any conflict between this Agreement and any terms or conditions of any document prepared or provided by Consultant and made a part of this Agreement, including without limitation any document relating to the scope of services or payment therefor, the terms of this Agreement shall control and prevail.
Professional Services Agreement
Form approved by the City Attorney 5-11-20
2. COMPENSATION
a. City shall pay Consultant for services rendered pursuant to this Agreement at the rates, times and in the manner set forth in Exhibit B. Consultant shall submit monthly statements to City which shall itemize the services performed as of the date of the statement and set forth a progress report, including work accomplished during the period, percent of each task completed, and planned effort for the next period. Invoices shall identify personnel who have worked on the services provided, the number of hours each worked during the period covered by the invoice, the hourly rate for each person, and the percent of the total project completed, consistent with the rates and amounts shown in Exhibit B.
b. The payments prescribed herein shall constitute all compensation to Consultant for all costs of services , including, but not limited to, direct costs of labor of employees engaged by Consultant, travel expenses, telephone charges, copying and reproduction, computer time, and any and all other costs, expenses and charges of Consultant, its agents and employees. In no event shall City be obligated to pay late fees or interest, whether or not such requirements are contained in Consultant’s invoice.
c. Notwithstanding any other provision in this Agreement to the contrary, the total maximum compensation to be paid for the satisfactory accomplishment and completion of all services to be performed hereunder shall in no event exceed the sum of [enter maximum amount in written and numeric form, for example – "ten-thousand, five-hundred dollars and no cents ($10,500.00)"]. The City’s Chief Financial Officer is authorized to pay all proper claims from Charge Number [enter IFAS charge number].
3. DOCUMENTATION; RETENTION OF MATERIALS
a. Consultant shall maintain adequate documentation to substantiate all charges as required under Section 2 of this Agreement.
b. Consultant shall keep and maintain full and complete documentation and accounting records concerning all extra or special services performed by it that are compensable by other than an hourly or flat rate and shall make such documents and records available to authorized representatives of City for inspection at any reasonable time.
c. Consultant shall maintain the records and any other records related to the performance of this Agreement and shall allow City access to such records during the performance of this Agreement and for a period of four (4) years after completion of all services hereunder.
4. INDEMNITY
a. Consultant shall, to the fullest extent permitted by law, indemnify, protect, defend and hold harmless City, and its employees, officials and ag ents ("Indemnified Parties") from all claims, demands, costs or liability (including liability for claims, suits, actions , arbitration proceedings, administrative proceedings, regulatory proceedings, losses, expenses or costs of any kind, interest, defense costs, and expert witness fees), that arise out of, pertain to, or relate to the negligence, recklessness, or willful misconduct of Consultant, its officers, employees, or agents, in said performance
Professional Services Agreement
Form approved by the City Attorney 5-11-20
of professional services under this Agreement, excepting only liability arising from the sole negligence, active negligence or intentional misconduct of City.
b. The existence or acceptance by City of any of the insurance policies or coverages described in this Agreement shall not affect or limit any of City’s rights under this Section 4, nor shall the limits of such insurance limit the liability of Consultant hereunder. This Section 4 shall not apply to any intellectual property claims, actions, lawsuits or other proceedings subject to the provisions of Section 17(b), below. The provisions of this Section 4 shall survive any expiration or termination of this Agreement.
5. INSURANCE
a. Consultant shall maintain in full force and effect all of the insurance coverage described in, and in accordance with, Attachment One, "Insurance Requirements ." Maintenance of the insurance coverage set forth in Attachment One is a material element of this Agreement and a material part of the consideration provided by Consultant in exchange for City’s agreement to make the payments prescribed hereunder. Failure by Consultant to (i) maintain or renew coverage, (ii) provide City notice of any changes, modifications, or reductions in coverage, or (iii) provide evidence of renewal, may be treated by City as a material breach of this Agreement by Consultant, whereupon City shall be entitled to all rights and remedies at law or in equity, including but not limited to immediate termination of this Agreement.
Notwithstanding the foregoing, any failure by Consultant to maintain required insurance coverage shall not excuse or alleviate Consultant from any of its other duties or obligations under this Agreement. In the event Consultant, with approval of City pursuant to Section 6 below, retains or utilizes any subcontractors or subconsultants in the provision of any servic es to City under this Agreement, Consultant shall assure that any such subcontractor has first obtained, and shall maintain, all of the insurance coverages set forth in the Insurance Requirements in Attachment One.
b. Consultant agrees that any available insurance proceeds broader than or in excess of the coverages set forth in the Insurance Requirements in Attachment One shall be available to the additional insureds identified therein.
c. Consultant agrees that the insurance coverages and limits provided under this Agreement are the greater of: (i) the coverages and limits specified in Attachment One, or (ii) the broader coverages and maximum limits of coverage of any insurance policy or proceeds available to the name insureds.
6. ASSIGNMENT
Consultant shall not assign any rights or duties under this Agreement to a third party without the express prior written consent of City, in City’s sole and absolute discretion. Consultant agrees that the City shall have the right to approve any and all subcontractors and subconsultants to be used by Consultant in the performance of this Agreement before Consultant contracts with or otherwise engages any such subcontractors or subconsultants.
Professional Services Agreement
Form approved by the City Attorney 5-11-20
7. NOTICES
Except as otherwise provided in this Agreement, any notice, submittal or communication required or permitted to be served on a party, shall be in writing and may be served by personal delivery to the person or the office of the person identified below. Service may also be made by mail, by placing first-class postage, and addressed as indicated below, and depositing in the United States mail to:
City Representative:
[Include name of Project Manager]
[Include Address and Telephone and
Facsimile Number]
Consultant Representative:
[Include name of Project
Manager]
[Include Address, Telephone and
Facsimile Number]
8. INDEPENDENT CONTRACTOR
a. It is understood and agreed that Consultant (including Consultant’s employees) is an independent contractor and that no relationship of employer -employee exists between the parties hereto for any purpose whatsoever. Neither Consultant nor Consultant’s assigned personnel shall be entitled to any benefits payable to employees of City. City is not required to make any deductions or withholdings from the compensation payable to Consultant under the provisions of this Agreement, and Consultant shall be issued a Form 1099 for its services hereunder. As an independent contractor, Consultant hereby agrees to indemnify and hold City harmless from any and all claims that may be made against City based upon any contention by any of Consultant’s employees or by any third party, including but not limited to any state or federal agency, that an employer -employee relationship or a substitute therefor exists for any purpose whatsoever by reason of this Agreement or by reason of the nature and/or performance of any services under this Agreement.
b. It is further understood and agreed by the parties hereto that Consultant, in the performance of Consultant’s obligations hereunder, is subject to the control and direction of City as to the designation of tasks to be performed and the results to be accomplished under this Agreement, but not as to the means, methods, or sequence used by Consultant for accomplishing such results. To the extent that Consultant obtains permission to, and does, use City facilities, space, equipment or support services in the performance of this Agreement, this use shall be at the Consultant’s sole discretion based on the Consultant’s determination that such use will promote Consultant’s efficiency and effectiveness.
Except as may be specifi cally provided elsewhere in this Agreement, the City does not require that Consultant use City facilities, equipment or support services or work in City locations in the performance of this Agreement.
c. If, in the performance of this Agreement, any third persons are employed by Consultant, such persons shall be entirely and exclusively under the direction, supervision, and control of Consultant. Except as may be specifically provided elsewhere in this Agreement, all terms of employment, including hours, wages, working conditions, discipline, hiring, and discharging, or any other terms of employment or requirements of law, shall be determined by Consultant. It is further understood and agreed that Consultant shall issue W-2 or 1099 Forms for income and employment tax purposes, for
Professional Services Agreement
Form approved by the City Attorney 5-11-20
all of Consultant’s assigned personnel and subcontractors.
d. The provisions of this Section 8 shall survive any expiration or termination of this Agreement. Nothing in this Agreement shall be construed to create an exclusive relationship between City and Consultant. Consultant may represent, perform services for, or be employed by such additional persons or companies as Consultant sees fit.
9. ADDITIONAL SERVICES
Changes to the Scope of Services shall be by written amendment to this Agreement and shall be paid on an hourly basis at the rates set forth in Exhibit B, or paid as otherwise agreed upon by the parties in writing prior to the provision of any such additional services.
10. SUCCESSORS AND ASSIGNS
City and Consultant each binds itself, its partners, successors, legal representatives and assigns to the other party to this Agreement and to the partners, successors, legal representatives and assigns of such other party in respect of all promises and agreements contained herein.
11. TERM, SUSPENSION, TERMINATION
a. This Agreement shall become effective on the date that it is made, set forth on the first page of the Agreement, and shall continue in effect until both parties have fully performed their respective obligations under this Agreement, unless sooner terminated as provided herein.
b. City shall have the right at any time to temporarily suspend Consultant’s performance hereunder, in whole or in part, by giving a written notice of suspension to Consultant. If City gives such notice of suspension, Consultant shall immediately suspend its activities under this Agreement, as specified in such notice.
c. City shall have the right to terminate this Agreement for convenience at any time by giving a written notice of termination to Consultant. Upon such termination, Consultant shall submit to City an itemized statement of services performed as of the date of termination in accordance with Section 2 of this Agreement. These services may include both completed work and work in progress at the time of termination. City shall pay Consultant for any services for which compensation is owed; provided, however, City shall not in any manner be liable for lost profits that might have been made by Consultant had the Agreement not been terminated or had Consultant completed the services required by this Agreement. Consultant shall promptly deliver to City all documents related to the performance of this Agreement in its possession or control. All such documents shall be the property of City without additional compensation to Consultant.
12. TIME OF PERFORMANCE
The services described herein shall be provided during the period, or in accordance with the schedule, set forth in Exhibit A . Consultant shall complete all the required services and tasks and complete and tender all deliverables to the reasonable satisfaction of City, not later than [enter expected
Professional Services Agreement
Form approved by the City Attorney 5-11-20
completion date].
13. STANDARD OF PERFORMANCE
Consultant shall perform all services performed under this Agreement in the manner and according to the standards currently observed by a competent practitioner of Consultant’s profession in California. All products of whatsoever nature that Consultant delivers to City shall be prepared in a professional manner and conform to the standards of quality normally observed by a person currently practicing in Consultant’s profession, and shall be provided in accordance with any schedule of performance. Consultant shall assign only competent personnel to perform services under this Agreement. Consultant shall notify City in writing of any changes in Consultant’s staff assigned to perform the services under this Agreement prior to any such performance. In the event that City, at any time, desires the removal of any person assigned by Consultant to perform services under this Agreement, because City, in its sole discretion, determines that such person is not performing in accordance with the standards required herein, Consultant shall remove such person immediately upon receiving notice from City of the desire of City for the removal of such person.
14. CONFLICTS OF INTEREST
Consultant covenants that neither it, nor any officer or principal of its firm, has or shall acquire any interest, directly or indirectly, that would conflict in any manner with the interests of City or that would in any way hinder Consultant’s performance of services under this Agreement. Consultant further covenants that in the performance of this Agreement, no person having any such interest shall be employed by it as an officer, employee, agent or subcontractor, without the written consent of City. Consultant agrees to avoid conflicts of interest or the appearance of any conflicts of interest with the interests of City at all times during the performance of this Agreement.
15. CONFLICT OF INTEREST REQUIREMENTS
a. Generally. The City’s Conflict of Interest Code requires that individuals who qualify as "consultants" under the Political Reform Act, California Government Code sections 87200 et seq., comply with the conflict of interest provisions of the Political Reform Act and the City’s Conflict of Interest Code, which generally prohibit individuals from making or participating in the making of decisions that will have a material financial effect on their economic interests. The term "consultant" generally includes individuals who make governmental decisions or who serve in a staff capacity.
b. Conflict of Interest Statements. The individual(s) who will provide services or perform work pursuant to this Agreement are "consultants" within the meaning of the Political Reform Act and the City’s Conflict of Interest Code:
____ yes ____ no (check one)
If "yes" is checked by the City, Consultant shall cause the following to occur within 30 days after execution of this Agreement:
Professional Services Agreement
Form approved by the City Attorney 5-11-20
(1) Identify the individuals who will provide services or perform work under this Agreement as "consultants"; and
(2) Cause these individuals to file with the City Clerk the assuming office statements of economic interests required by the City’s Conflict of Interest Code.
Thereafter, throughout the term of the Agreement, Consultant shall cause these individuals to file with the City Clerk annual statements of economic interests, and "leaving office" statements of economic interests, as required by the City’s Conflict of Interest Code.
The above statements of economic interests are public records subject to public disclosure under the California Public Records Act. The City may withhold all or a portion of any payment due under this Agreement until all required statements are filed.
16. CONFIDENTIALITY OF CITY INFORMATION
During performance of this Agreement, Consultant may gain access to and use City information regarding inventions, machinery, products, prices, apparatus, costs, discounts, future plans, business affairs, governmental affairs, processes, trade secrets, technical matters, systems, facilities, customer lists, product design, copyright, data, and other vital information (hereafter collectively referred to as "City Information") that are valuable, special and unique assets of the City. Consultant agrees to protect all City Information and treat it as strictly confidential, and further agrees that Consultant shall not at any time, either directly or indirectly, divulge, disclose or communicate in any manner any City Information to any third party without the prior written consent of City. In addition, Consultant shall comply with all City policies governing the use of the City network and technology systems. A violation by Consultant of this Section 16 shall be a material violation of this Agreement and shall justify legal and/or equitable relief.
17. CONSULTANT INFORMATION
a. City shall have full ownership and control, including ownership of any copyrights, of all information prepared, produced, or provided by Consultant pursuant to this Agreement. In this Agreement, the term "information" shall be construed to mean and include: any and all work product, submittals, reports, plans, specifications, and other deliverables consisting of documents, writings, handwritings, typewriting, printing, photostatting, photographing, computer models, and any other computerized data and every other means of recording any form of information, communications, or representation, including letters, works, pictures, drawings, sounds, or symbols, or any combination thereof. Consultant shall not be responsible for any unauthorized modification or use of such information for other than its intended purpose by City.
b. Consultant shall fully defend, indemnify and hold harmless City, its officers and employees, and each and every one of them, from and against any and all claims, actions, lawsuits or other proceedings alleging that all or any part of the information prepared, produced, or provided by Consultant pursuant to this Agreement infringes upon any third party’s trademark, trade name, copyright, patent or other intellectual property rights. City shall make reasonable efforts to notify Consultant not
Professional Services Agreement
Form approved by the City Attorney 5-11-20
later than ten (10) days after City is served with any such claim, action, lawsuit or other proceeding, provided that City’s failure to provide such notice within such time period shall not relieve Consultant of its obligations hereunder, which shall survive any termination or expiration of this Agreement.
c. All proprietary and other information received from Consultant by City, whether received in connection with Consultant’s proposal , will be disclose d upon receipt of a request for disclosure, pursuant to the California Public Records Act; provided, however, that, if any information is set apart and clearly marked "trade secret" when it is provided to City, City shall give notice to Consultant of any request for the disclosure of such information. Consultant shall then have five (5) days from the date it receives such notice to enter into an agreement with the City, satisfactory to the City Attorney, providing for the defense of, and complete indemnifi cation and reimbursement for all costs (including plaintiff’s attorneys’ fees) incurred by City in any legal action to compel the disclosure of such information under the California Public Records Act. Consultant shall have sole responsibility for defense of the actual "trade secret" designation of such information.
d. The parties understand and agree that any failure by Consultant to respond to the notice provided by City and/or to enter into an agreement with City, in accordance with the provisions of subsection c, above, shall constitute a complete waiver by Consultant of any rights regarding the information designated "trade secret" by Consultant, and such information shall be disclosed by City pursuant to applicable procedures required by the Public Records Act.
18. MISCELLANEOUS
a. Entire Agreement. This Agreement contains the entire agreement between the parties.
Any and all verbal or written agreements made prior to the date of this Agreement are superseded by this Agreement and shall have no further effect.
b. Modification. No modification or change to the terms of this Agreement will be binding on a party unless in writing and signed by an authorized representative of that party.
c. Compliance with Laws. Consultant shall perform all services described herein in compliance with all applicable federal, state and local laws, rules, regulations, and ordinances, including but not limited to, (i) the Americans with Disabilities Act of 1990 (42 U.S.C. 12101, et seq.) ("ADA"), and any regulations and guidelines issued pursuant to the ADA; and (ii) Labor Code s ections 1720, et seq., which require prevailing wages (in accordance with DIR determinations at www.dir.ca.gov) be paid to any employee performing work covered by Labor Code s ections 1720 et seq. Consultant shall pay to the City when due all business taxes payable by Consultant under the provisions of Chapter 6-04 of the Santa Rosa City Code. The City may deduct any delinquent business taxes, and any penalties and interest added to the delinquent taxes, from its payments to Consultant.
d. Discrimination Prohibited. With respect to the provision of services under this Agreement, Consultant agrees not to discriminate against any person because of the race, religious creed, color, national origin, ancestry, physical disability, mental disability, medical condition, genetic information, marital status, sex, gender, gender identity, gender expression, age, sexual orientation, or military and veteran status of that person.
Professional Services Agreement
Form approved by the City Attorney 5-11-20
e. Governing Law; Venue. This Agreement shall be governed, construed and enforced in accordance with the laws of the State of California. Venue of any litigation arising out of or connected with this Agreement shall lie exclusively in the state trial court in Sonoma County in the State of California, and the parties consent to jurisdiction over their persons and over the subject matter of any such litigation in such court, and consent to service of process issued by such court.
f. Waiver of Rights. Neither City acceptance of, or payment for, any service or performed by Consultant, nor any waiver by either party of any default, breach or condition precedent, shall be construed as a waiver of any provision of this Agreement, nor as a waiver of any other default, breach or condition precedent or any other right hereunder.
g. Incorporation of Attachments and Exhibits. The attachments and exhibits to this Agreement are incorporated and made part of this Agreement, subject to terms and provisions herein contained.
19. AUTHORITY; SIGNATURES REQUIRED FOR CORPORATIONS
Consultant hereby represents and warrants to City that it is (a) a duly organized and validly existing [enter type of entity], formed and in good standing under the laws of the State of [enter state of formation for corporations, LPs and LLCs], (b) has the power and authority and the legal right to conduct the business in which it is currently engaged, and (c) has all requisite power and authority and the legal right to consummate the transactions contemplated in this Agreement. Consultant hereby further represents and warrants that this Agreement has been duly authorized, and when executed by the signatory or signatories listed below, shall constitute a valid agreement binding on Consultant in accordance with the terms hereof.
If this Agreement is entered into by a corporation, it shall be signed by two corporate officers, one from each of the following two groups: a) the chairman of the board, president or any vice- president; b) the secretary, any assistant secretary, chief financial officer, or any assistant treasurer. The title of the corporate officer shall be listed under the signature.
20. COUNTERPARTS AND ELECTRONIC SIGNATURES
This Agreement and future documents relating thereto may be executed in two or more counterparts, each of which will be deemed an original and all of which together constitute one Agreement. Counterparts and/or signatures delivered by facsimile, pdf or City-approved electronic means have the same force and effect as the use of a manual signature. Both City and Consultant wish to permit this Agreement and future documents relating thereto to be electronically signed in accordance with applicable federal and California law. Either Party to this Agreement may revoke its permission to use electronic signatures at any time for future documents by providing notice pursuant to the Agreement.
The Parties agree that electronic signatures, by their respective signatories are intended to authenticate such signatures and to give rise to a valid, enforceable, and fully effective Agreement. The City reserves the right to reject any signature that cannot be positively verified by the City as an authentic electronic signature.
Professional Services Agreement
Form approved by the City Attorney 5-11-20
Executed as of the day and year first above stated.
CONSULTANT:
Name of Firm:________________________
TYPE OF BUSINESS ENTITY (check one):
_____ Individual/Sole Proprietor
_____Partnership
_____Corporation
_____ Limited Liability Company
_____ Other (please specify: ___________)
Signatures of Authorized Persons:
By: _____________________________
Print Name:_______________________
Title: ____________________________
By: _____________________________
Print Name:_______________________
Title: ____________________________
City of Santa Rosa Business Tax Cert. No.
__________________________________
CITY OF SANTA ROSA
a Municipal Corporation
By:________________________________
Print
Name:_____________________________
Title:_______________________________
APPROVED AS TO FORM:
____________________________
Office of the City Attorney
ATTEST:
____________________________
City Clerk
[Remove signature block if agreement not
approved by Council]
Attachments:
Attachment One - Insurance Requirements
Exhibit A - Scope of Services
Exhibit B - Compensation
Form approved by the City Attorney
12-13-14
ATTACHMENT ONE
INSURANCE REQUIREMENTS
A. Insurance Policies: Licensee shall, at all times during the term of the License, maintain and keep in full force and effect, the following policies of insurance with minimum coverage as indicated below and issued by insurers with AM Best ratings of no less than A -:VI or otherwise acceptable to the City.
Insurance
Minimum
Coverage
Limits
Additional Coverage Requirements
1. Commercial
general liability
$ 1 million per
occurrence
Coverage must be at least as broad as ISO CG 00
01 and must include completed operations coverage.
If insurance applies separately to a project/location,
aggregate may be equal to per occurrence amount.
Coverage may be met by a combination of
primary and umbrella or excess insurance but
umbrella and excess shall provide coverage at
least as broad as specified for underlying
coverage. Coverage shall not exclude
subsidence.
$ 2 million
aggregate
2. Business auto
coverage
$ 1 million ISO Form Number CA 00 01 covering any auto
(Code 1), or if Licensee has no owned autos, then
hired, (Code 8) and non-owned autos (Code 9), with
limit no less than $ 1 million per accident for bodily
injury and property damage.
3. Workers’
compensation
and employer’s
liability
$ 1 million As required by the State of California, with Statutory Limits and Employer’s Liability Insurance with limit of no less than $ 1 million per accident for bodily injury or disease. The Workers’ Compensation policy shall
be endorsed with a waiver of subrogation in favor of
the City for all work performed by the Licensee , its
employees, agents and subcontractors.
4. Pollution Liability
$ 1 million
If the work involves lead- based paint or asbestos
identification/remediation, the policy must not
contain lead-based paint or asbestos exclusions. If
the work involves mold identification, the policy must
not contain mold exclusion and the definition of
Form approved by the City Attorney
12-13-14
“Pollution” in the policy must include microbial
matter, including mold.
B. Endorsements:
1. All policies shall provide or be endorsed to provide that coverage shall not be canceled by either party, except after prior written notice has been provided to the entity in accordance with the policy provisions.
2. Liability, umbrella and excess policies shall provide or be endorsed to provide the following:
a. For any claims related to this project, Licensee’s insurance coverage shall be primary and any insurance or self-insurance maintained by City shall be excess of the Licensee’s insurance and shall not contribute with it; and, b. The City of Santa Rosa, its officers, agents, employees and volunteers are to be covered as additional insureds on the CGL policy . General liability coverage can be provided in the form of an endorsement to Licensee’s insurance at least as broad as ISO Form CG 20 10 11 85 or if not available, through the addition of both CG 20 10 and CG 20 37 if a later edition is used.
C. Verification of Coverage and Certificates of Insurance: Licensee shall furnish City with original certificates and endorsements effecting coverage required above.
Certificates and endorsements shall make reference to policy numbers. All certificates and endorsements are to be received and approved by the City before work commences and must be in effect for the duration of the Agreement. The City reserves the right to require complete copies of all required policies and endorsements.
D. Other Insurance Provisions:
1. No policy required by this Agreement shall prohibit Licensee from waiving any right of recovery prior to loss. Licensee hereby waives such right with regard to the indemnitees.
2. All insurance coverage amounts provided by Licensee and available or applicable to this Agreement are intended to apply to the full extent of the policies. Nothing contained in this Agreement limits the application of such insurance coverage.
Defense costs must be paid in addition to coverage amounts.
3. Policies containing any self -insured retention (SIR) provision shall provide or be endorsed to provide that the SIR may be satisfied by either Licensee or City. Self- insured retentions above $10,000 must be approved by City. At City’s option, Licensee may be required to provide financial guarantees.
4. Sole Proprietors must provide a representation of their Workers’ Compensation Insurance exempt status.
City reserves the right to modify these insurance requirements while this Agreement is in effect, including limits, based on the nature of the risk, prior experience, insurer, coverage, or other special circumstances.
1 PROFESSIONAL SERVICES AGREEMENT (City)
(iManage #609321) April 2010
PROFESSIONAL SERVICES AGREEMENT
(Title of Project)
FY Fund # Exp. Acct. # Project # Amount $ For multi-year contracts or contracts with multiple accounts:
FY Fund # Exp. Acct. # Project # Amount $ FY Fund # Exp. Acct. # Project # Amount $ FY Fund # Exp. Acct. # Project # Amount $ FY Fund # Exp. Acct. # Project # Amount $ FY Fund # Exp. Acct. # Project # Amount $
THIS PROFESSIONAL SERVICES AGREEMENT (“Agreement”) is entered into and effective as of __________________, 20____ (“Effective Date”), by and between the City of Petaluma, a municipal corporation and a charter city (“City”) and , a (“Consultant”) (collectively, the “Parties”).
WHEREAS, the Parties enter into this Agreement for the purpose of Consultant providing professional services to City under the terms and conditions set forth herein.
THEREFORE, in consideration of the mutual covenants contained in this Agreement, the Parties agree as follows:
1. Services. Consultant shall provide the services as described in and in accordance with the schedule set forth in Exhibit “A” attached hereto and incorporated herein (“Services”).
2. Compensation; Business Tax Certificate.
A. For the full performance of the Services as described herein, City shall compensate Consultant under the following terms: .
B. Consultant shall submit detailed monthly invoices reflecting all services performed during the preceding month, and including a revised schedule for performance and additional documentation requested by City, as applicable.
C. Consultant shal l be compensated for services in addition to those described in Exhibit A, only if Consultant and City execute a written amendment to this Agreement describing the additional services to be performed and the compensation to be paid for such services. In no case shall the total compensation under this Agreement exceed without prior written authorization of the City Manager. Further, no compensation for a section or work program component attached with a specific budget shall be exceeded without prior written authorization of the City Manager.
D. Notwithstanding any provision herein, Consultant shall not be paid any compensation until such time as Consultant has on file with the City Finance Department current information requested on the “Vendor Information” form available from City, and has obtained a currently valid Petaluma business tax certificate.
2 PROFESSIONAL SERVICES AGREEMENT (City)
(iManage #609321) April 2010
E. City’s obligation to pay compensation to Consultant as provided herein is contingent upon Consultant’s performance of the Services pursuant to the terms and conditions of this Agreement and any amendments thereto.
3. Term. The term of this Agreement commences on the Effective Date, and terminates on , unless sooner terminated in accordance with Section 4. Upon termination, any and all of City’s documents or materials provided to Consultan t and any and all of the documents or materials prepared for City or relating to the performance of the Services, shall be delivered to the City as soon as possible, but not later than fourteen (14) days after termination of the Agreement.
4. Termination. City may terminate this Agreement without cause upon ten (10) days’ written notice. City may immediately terminate or suspend this Agreement for cause.
Cause for immediate termination or suspension shall include, but not be limited to, any breach of this Agreement by Consultant or Consultant’s bankruptcy or insolvency. Upon receipt of notice of termination or suspension for cause, Consultant shall immediately stop all work in progress under this Agreement. In the event of early termination of this Agreement by City, Consultant shall be entitled to payment for all Services performed to the date of termination to the extent such Services were performed to the satisfaction of City in accordance with the terms and conditions of this Agreement. If City terminates this Agreement for cause, Consultant shall be liable to City for any excess cost City incurs for completion of the Services.
5. Consultant’s Representation; Independent Contractor . Consultant represents that Consultant possesses distinct professional skills in performing the Services. City has relied upon said representation as a material inducement to enter into this Agreement.
Consultant shall, therefore, provide properly skilled professional and technical personnel to perform all Services under this Agreement. It is expressly understood that Consultant and its agents and employees, shall act in an independent capacity and as an independent contractor and not as officers, employees or agents of City. This Agreement shall not be construed as an agreement for employment.
6. Facilities and Equipment . Consultant shall, at its sole cost and expense, furnish all facilities and equipment that may be required for furnishing Services pursuant to this Agreement. City shall furnish to Consultant no facilities or equipment, unless the City otherwise agrees in writing to provide the same.
7. Licenses, Permits, Etc. Consultant shall, at Consultant’s sole cost and expense, keep in effect at all times during the term of this Agreement any licenses, permits or other such approvals which are legally required for performing the Services.
8. Time. Consultant shall devote such time to the performance of the Services as may be reasonably necessary for satisfactory performance of Consultant’s obligations pursuant to this Agreement.
9. Inspection. Consultant shall provide the City every reasonable opportunity to ascertain that the Services are being performed in accordance with the requirements and intentions of this Agreement. All work done and materials furnished, if any, shall be subject to inspection and approval by the City. The inspection of such work shall not relieve Consultant of any of its obligations pursuant to this Agreement. 3 PROFESSIONAL SERVICES AGREEMENT (City)
(iManage #609321) April 2010
10. Progress Reports . Upon the City’s request, Consultant shall provide, in a form acceptable to City, written progress reports of all oral and written observations, opinions, recommendations, analyses, progress and conclusions related to Consultant’s performance of the Services.
11. Confidentiality. In the course of Consultant’s employment, Consultant may have access to trade secrets and confidential information, disclosure of which is protected or limited by law. Consultant shall not directly or indirectly disclose or use any such confidential information, except as required for the performance of the Services.
12. Conflict of Interest . Consultant represents that it presently has no interest, and covenants that it shall not acquire any interest, direct or indirect, financial or otherwise, which would conflict in any manner or degree with the performance of the Services hereunder. Consultant further covenants that, in the performance of this Agreement, it shall not employ any subcontractor or person having such a conflict of interest.
Consultant represents that no one who has or will have any financial interest under the Agreement is an officer or employee of City. If such conflict of interest arises during this Agreement or any extension, Consultant will immediately advise City and City may, at its sole discretion, immediately terminate this Agreement. Certain Consultants are subject to the requirements, including the disclosure and reporting requirements, of the City’s Conflict of Interest Code adopted pursuant to the Political Reform Act. Such Consultants subject to the City’s Conflict of Interest Code include those whose work may involve: making government decisions regarding approval or adoption of rates, rules, or regulations, action on permits or other applications, authorization to enter into or modify contracts, or approval of plans, designs, reports, or studies. Consultant agrees to comply fully with all such requirements to the extent they apply to Consultant’s performance of the Services.
13. Consultant No Agent . Except as City may specify in writing, Consultant shall have no authority, express or implied, to act on behalf of City in any capacity whatsoever as an agent. Consultant shall have no authority, express or implied, pursuant to this Agreement to bind City to any obligation whatsoever.
14. Standard of Performance . Consultant shall perform all the Services in a manner consistent with the standards of Consultant’s profession. All instruments of service of whatsoever nature, which Consultant delivers to City pursuant to this Agreement, shall be prepared in a substantial, first class and workmanlike manner and conform to the standards of Consultant’s profession. All such instruments of service shall become the sole and exclusive property of City upon delivery of the same.
15. Assignment/Transfer. No assignment or transfer in whole or in part of this Agreement shall be made without the prior written consent of City.
16. Subcontractors. Consultant shall directly perform all Services, and shall not subcontract any portion of performance of the Services without the prior written consent of City.
Any such subcontractors shall be required to comply, to the full extent applicable, with the terms and conditions of this Agreement, including but not limited to, procuring and maintaining insurance coverage as required herein and which shall name City as an additional insured.
4 PROFESSIONAL SERVICES AGREEMENT (City)
(iManage #609321) April 2010
17. Compliance With All Laws . Consultant shall fully comply with all applicable local, state and federal rules, laws, regulations and ordinances pertaining to the performance of the Services required hereunder , including but not limited to, the California Building Standards Code as in effect in the City, the Americans with Disabilities Act, and any laws and regulations related to any copyright, patent, trademark or other intellectual property right involved in performance of the Services . Consultant’s failure to comply with any law(s) or regulation(s) applicable to the performance of the Services hereunder shall constitute a material breach of this Agreement. To the extent that any other government agency or entity provides compensation for any Services, Consultant shall comply with all rules and regulations applicable to such fiscal assistance.
18. Living Wage Ordinance . Without limiting the foregoing Section 17, Consultant shall comply fully with the requirements of Petaluma Municipal Code, Chapter 8.36, Living Wage (the “Living Wage Ordinance”), as the same may be amended from time to time.
Upon the City’s request Consultant shall promptly provide to the City documents and information verifying Consultant’s compliance with the requirements of the Living Wage Ordinance, and shall within fifteen (15) calendar days of the Effective Date of this Agreement, notify each of its affected employees as to the amount of wages and time off that are required to be provided to them pursuant to the Living Wage Ordinance.
Consultant’s noncompliance with the Living Wage Ordinance shall constitute cause for City’s termination of this Agreement pursuant to Section 4 hereof.
19. Discrimination. During the performance of this Agreement, Consultant shall not discriminate against any employee or applicant for employment because of race, religion, creed, color, national origin, ancestry, gender, sexual orientation, age or physical or mental disability in violation of any applicable law.
20. Notice. Except as otherwise specified in this Agreement, all notices to be sent pursuant to this Agreement shall be made in writing, and sent to the Parties at their respective addresses specified below or to such other address as a Party may designate by written notice delivered to the other Party in accordance with this Section. All such notices shall be sent by:
(i) personal delivery, in which case notice is effective upon delivery; (ii) certified or registered mail, return receipt requested, in which case notice shall be deemed delivered on receipt if delivery is confirmed by a return receipt; (iii) nationally recognized overnight courier, with charges prepaid or charged to the sender’s account, in which case notice is effective on delivery if delivery is confirmed by the delivery service; or
(iv) facsimile transmission, in which case notice shall be deemed delivered upon transmittal, provided that (a) a duplicate copy of the notice is promptly delivered by first -class or certified mail or by overnight delivery, or (b) a transmission report is generated reflecting the accurate transmission thereof. Any notice given by facsimile shall be considered to have been received on the next business day if it is received after 5:00 p.m. recipient’s time or on a nonbusiness day.
City: City Clerk
City of Petaluma
5 PROFESSIONAL SERVICES AGREEMENT (City)
(iManage #609321) April 2010
Post Office Box 61
Petaluma, California 94953
Phone: (707) 778-4360
Fax: (707) 778-4554
Email: [email protected]
And:
Phone:
Fax:
Email:
Consultant:
Phone:
Fax:
Email:
21. Ownership of Documents. All original papers, documents or computer material on disk or microfilm, and copies thereof, produced as a result of this Agreement, shall be the property of City and may not be used by Consultant without the written consent of City.
Copies of such documents or papers shall not be disclosed to others without the written consent of the City Manager or his or her designated representative.
22. Indemnification. To the maximum extent permitted by law, Consultant shall, at its own expense, indemnify, defend with counsel acceptable to the City, (which acceptance will not be unreasonably withheld), and hold harmless City and its officers, officials, employees, agents and volunteers (“Indemnitees”) from and against any and all liability, loss, damage, claims, suits, actions, arbitration proceedings, administrative proceedings, regulatory proceedings, civil penalties and fines, expenses and costs (including, without limitation, claims expenses, attorney’s fees and costs and fees of litigation) (collectively, “Liability”) of every nature, whether actual, alleged or threatened, arising out of or in connection with the Services or Consultant’s failure to comply with any of the terms of this Agreement, regardless of any fault or alleged fault of the Indemnitees.
The Consultant’s obligation to indemnify, defend and hold harmless under this provision shall not be excused because of the Consultant’s inability to evaluate Liability, or because the Consultant evaluates Liability and determines that the Consultant is not or may not be liable. The Consultant must respond within 30 calendar days to any tender for defense and indemnity by the City, unless the time for responding has been extended by an authorized representative of the City in writing. If the Consultant fails to accept tender of defense and indemnity within 30 calendar days, in addition to any other remedies authorized by law, so much of the money due or that may become due the Consultant under this Agreement as shall reasonably be considered necessary by the City, may be 6 PROFESSIONAL SERVICES AGREEMENT (City)
(iManage #609321) April 2010
retained by the City until disposition has been made of the matter subject to tender, or until the Consultant accepts the tender, whichever occurs first. In the event that the City must file responsive documents in a matter tendered to Consultant prior to Consultant’s acceptance of tender, Consultant agrees to fully reimburse all costs, including but not limited to attorney’s fees and costs and fees of litigation, incurred by the City in filing such responsive documents.
The Consultant waives any and all rights to express or implied indemnity against the Indemnitees concerning any Liability of the Consultant arising out of or in connection with the Services or Consultant’s failure to comply with any of the terms of this Agreement.
Notwithstanding the foregoing, to the extent this Agreement is a “construction contract” as defined by California Civil Code Section 2783, as may be amended from time to time, Consultant’s duty to indemnify under this provision shall not apply when to do so would be prohibited by California Civil Code Section 2782, as may be amended from time to time.
Notwithstanding the foregoing, to the extent that the Services include design professional services subject to California Civil Code Section 2782.8, as may be amended from time to time, Consultant’s duty to indemnify shall only be to the maximum extent permitted by California Civil Code Section 2782.8.
23. Insurance. Consultant shall comply with the “Insurance Requirements for Consultants” in Exhibit B - , attached hereto and incorporated herein by reference. [ Indicate attached exhibit, e.g., “B-1,” “B-2,” “B-3,” or “B-4.”]
24. Amendment. This Agreement may be amended only by a written instrument executed by both Parties.
25. Litigation. If lit igation ensues which pertains to the subject matter of Consultant’s services hereunder, Consultant, upon request from City, agrees to testify therein at a reasonable and customary fee.
26. Construction. This Agreement is the product of negotiation and compromise on the part of both Parties and that the Parties agree th at, notwithstanding Civil Code S ection 1654, any uncertainty in the Agreement shall not be construed against the drafter of the Agreement.
27. Governing Law; Venue . This Agreement shall be enforced and interpreted under the laws of the State of California and the City of Petaluma. Any action arising from or brought in connection with this Agreement shall be venued in a court of competent jurisdiction in the County of Sonoma, State of California.
28. Non-Waiver. The City’s failure to enforce any provision of this Agreement or the waiver thereof in a particular instance shall not be construed as a general waiver of any part of such provision. The provision shall remain in full force and effect.
7 PROFESSIONAL SERVICES AGREEMENT (City)
(iManage #609321) April 2010
29. Severability. If any term or portion of this Agreement is held to be invalid, illegal, or otherwise unenforceable by a court of competent jurisdiction, the remaining provisions of this Agreement shall continue in full force and effect.
30. No Third Party Beneficiaries . The Parties do not intend to create, and nothing in this Agreement shall be construed to create any benefit or right in any third party.
31. Mediation. The Parties agree to make a good faith attempt to resolve any dispute arising out of this Agreement through mediation prior to commencing litigation. The Parties shall mutually agree upon the mediator and shall divide the costs of mediation equally.
32. Consultant’s Books and Records.
A. Consultant shall maintain any and all ledgers, books of accounts, invoices, vouchers, canceled checks, and other records or documents evidencing or relating to charges for services, or expenditures and disbursements charged to the City for a minimum period of three (3) years or for any longer period required by law, from the date of final payment to Consultant pursuant to this Agreement.
B. Consultant shall maintain all documents and records which demonstrate performance under this Agreement for a minimum period of three (3) years or for any longer period required by law, from the date of termination or completion of this Agreement.
C. Any records or documents required to be maintained pursuant to this Agreement shall be made available for inspection or audit, at any time during regular business hours, upon written request by the City Manager, City Attorney, City Finance Director, or a designated representative of these officers. Copies of such documents shall be provided to the City for inspection at Petaluma City Hall when it is practical to do so. Otherwise, unless an alternative is mutually agreed upon, the records shall be available at Consultant’s address indicated for receipt of notices in this Agreement.
D. Where City has reason to believe that such records or documents may be lost or discarded due to dissolution, disbandment or termination of Consultant’s business, City may, by written request by any of the above -named officers, require that custody of the records be given to the City and that the records and documents be maintained in Petaluma City Hall. Access to such records and documents shall be granted to any party authorized by Consultant, Consultant’s representatives, or Consultant’s successor in interest.
33. Headings. The headings used in this Agreement are for convenience only and are not intended to affect the interpretation or construction of any provisions herein.
34. Survival. All obligations arising prior to the termination or expiration of this Agreement and all provisions of this Agreement allocating liability between City and Consultant shall survive the termination or expiration of this Agreement.
35. Entire Agreement . This Agreement, including the exhibits attached hereto and incorporated herein, constitutes the entire agreement between the Parties with respect to the Services, and super sedes all prior agreements or understandings, oral or written, between the Parties in this regard.
8 PROFESSIONAL SERVICES AGREEMENT (City)
(iManage #609321) April 2010
IN WITNESS WHEREOF, the parties hereto have executed this document the day, month and year first above written.
CITY OF PETALUMA CONSULTANT
By
City Manager Name
ATTEST:
Title
City Clerk Address
APPROVED AS TO FORM:
City State Zip
City Attorney Taxpayer I.D. Number
APPROVED:
Petaluma Business Tax Certificate Number
Department Director
APPROVED:
Risk Manager
APPROVED:
Finance Director
file name:
INSURANCE REQUIREMENTS (City)
March 2021
EXHIBIT B
INSURANCE REQUIREMENTS
FOR ALL AGREEMENTS
Contractor’s performance of the Services under this Agreement shall not commence until Contractor shall have obtained all insurance required under this paragraph and such insurance shall have been approved by the City Attorney as to form and the Risk Manager as to carrier and sufficiency. All requirements herein provided shall appear either in the body of the insurance policies or as endorsements and shall specifically bind the insurance carrier.
Contractor shall procure and maintain for the duration of the contract all necessary insurance against claims now and in the future for injuries to persons or damages to property which may arise from or in connection with the perf ormance of the Services by the Contractor, the Contractor’s agents, representatives, employees and subcontractors.
A. Required Minimum Scope of Insurance
☒ Coverage shall be at least as broad as:
Insurance Services Office Commercial General Liability coverage:
a. Personal injury;
b. Contractual liability.
☐ Insurance Services Office form covering Automobile Liability (any auto), if no company owned autos, non-owned and hired auto applies.
☒ Workers’ Compensation insurance as required by the State of California and Employer’s Liability Insurance.
☒ Professional Liability/Errors and Omissions
☐ Crime/Employee Blanket Fidelity Bond
☐ Property Insurance against all risks of loss to any tenant improvements or betterments. ☐ Pollution Liability Insurance
☐ Garage Liability
☐ Garagekeepers Insurance
☐ Technology Professional Liability Errors and Omissions Insurance (IT Consultant)/Cyber Liability
☐ Abuse or Molestation Liability Coverage
A.1 Required for All Contracts
☒ Policy Endorsements or Excerpts from the Policy Pursuant to Section D ☒ Copy of the Declarations and Policy Endorsements Page for the CGL Policy
B. Minimum Limits of Insurance
Consultant shall maintain limits no less than:
☒ General Liability: $1,000,000 per occurrence for bodily injury, personal injury and property damage. If Commercial General Liability Insurance or other form with a general aggregate liability is used, either the general aggregate limit shall apply separately to this Agreement or the general aggregate limit shall be twice the required occurrence limit. ☐ Products/Completed Operations: $1,000,000 per occurrence/aggregate. ☐ Automobile Liability: $1,000,000 per accident for bodily injury and property damage. ☐ Employer’s Liability: Bodily Injury by Accident - $1,000,000 each accident.
INSURANCE REQUIREMENTS (City)
March 2021
Bodily Injury by Disease - $1,000,000 policy limit.
Bodily Injury by Disease - $1,000,000 each employee.
☒ Professional Liability/Errors and Omissions: $1,000,000 per occurrence or claim. If the policy provides coverage on a claims-made basis, the retroactive date must be shown and must be before the date of the Agreement or the beginning of the contract work. ☐ Crime/Employee Blanket Fidelity Bond - $1,000,000: Contractor, at its own cost and expense, must maintain a Crime/Employee Blanket Fidelity Bond in the amount of $1,000,000 per employee covering dishonesty, forgery, alteration, theft, disappearance, destruction (inside or outside).
☐ All Risk Property Insurance: Full replacement cost. ☐ Pollution legal liability with limits no less than $1,000,000 per occurrence or claim and $2,000,000 policy aggregate. If the policy provides coverage on a claims-made basis, the retroactive date must be shown and must be before the date of the Agreement or the beginning of the contract work.
☐ Garage Liability: $1,000,000 per occurrence.
☐ Garagekeepers Insurance: $1,000,000 per occurrence. ☐ Technology Professional Liability Errors and Omissions Insurance appropriate to the Consultant’s profession and work hereunder, with limits not less than $1,000,000 per occurrence. Coverage shall be sufficiently broad to respond to the duties and obligations as is undertaken by the Vendor in this agreement and shall include, but not be limited to, claims involving infringement of intellectual property, copyright, trademark, invasion of privacy violations, information theft, release of private information, extortion and network security. The policy shall provide coverage for breach response costs as well as regulatory fines and penalties as well as credit monitoring expenses with limits sufficient to respond to these obligations.
1. The Policy shall include, or be endorsed to include, property damage liability coverage for damage to, alteration of, loss of, or destruction of electronic data and/or information “property” of the City in the care, custody, or control of the Consultant. If not covered under the Consultant’s liability policy, such “property” coverage of the City may be endorsed onto the Consultant’s Cyber Liability as covered property as follows:
2. Cyber Liability coverage in an amount sufficient to cover the full replacement value of damage to, alteration of, loss of, or destruction of electronic data and/or information “property” of the City that will be in the care, custody, or control of the Consultant.
3. The Insurance obligations under this agreement shall be the greater of 1) all the Insurance coverage and limi ts carried by or available to the Consultant; or 2) the minimum Insurance requirements shown in this Agreement. Any insurance proceeds in excess of the specified limits and coverage required, which are applicable to a given loss, shall be available to the City. No representation is made that the minimum Insurance requirements of this Agreement are sufficient to cover the indemnity or other obligations of the Consultant under this agreement.
☐ Abuse or Molestation Liability Coverage: $1,000,000 per occurrence; $2,000,000 aggregate.
INSURANCE REQUIREMENTS (City)
March 2021
C. Deductibles and Self-Insured Retentions
Any deductibles or self-insured retentions must be declared to and approved by the City. At the option of the City, either: the insurer shall reduce or eliminate such deductibles or self - insured retentions as respects the City, its officers, officials, employees, and volunteers; or the Consultant shall procure a bond guaranteeing payment of losses and related investigations, claim administration and defense expenses. Policies containing any self -insured retention (SIR) provision shall provide or be endorsed to provide that the SIR may be satisfied by either the named insured (Contractor) or the City.
City reserves the right to review any and all of the required insurance policies , declaration pages, and/or endorsements, but has no obligation to do so. City’s failure to demand evidence of full compliance with the insurance requirements set forth in this Agreement or City’s failure to identify any insurance deficiency shall not relieve Contractor from, nor be construed or deemed a waiver of, its obligation to maintain the required insurance at all times during the performance of this Agreement.
D. Other Insurance Provisions
The required general liability and automobile policies are to contain, or be endorsed to contain the following provisions:
1. Additional Insured: The City, its officers, officials, employees, agents and volunteers are to be covered as Additional Insureds as respects: liability arising out of activities performed by or on behalf of the Consultant; products and completed operations of the Consultant; premises owned, occupied or used by the Consultant; or automobiles owned, leased, hired or borrow ed by the Consultant. The coverage shall contain no special limitations on the scope of protection afforded to the City, its officers, officials, employees, agents or volunteers.
2. Primary and Non-Contributory: For any claims related to this project, the Consultant’s insurance coverage shall be primary insurance as respects the City, its officers, officials, employees, agents and volunteers. Any insurance or self -insurance maintained by the City, its officers, officials, employees, agents or volunteers shall be excess of the Consultant’s insurance and shall not contribute with it.
3. Any failure to comply with reporting or other provisions of the policies including breaches of warranties shall not affect coverage provided to the City, its officers, officials, employees, agents or volunteers.
4. The Consultant’s insurance shall apply separately to each insured against whom claim is made or suit is brought except, with respect to the limits of the insurer’s liability.
5. Each insurance policy required by this clause shall be endorsed to state that coverage shall not be suspended, voided, canceled by either party, reduced in coverage or in limits except after thirty (30) days’ prior written notice by certified mail, return receipt requested, has been given to the City.
6. Waiver of Subrogation: Consultant agrees to waive subrogation rights for commercial general liability, automobile liability and worker’s compensation against City regardless of the applicability of any insurance proceeds, and to require all contractors, subcontractors or others involved in any way with the Services to do likewise.
7. It shall be a requirement under this Agreement that any available insurance proceeds broader than or in excess of the specified minimum insurance c overage requirement and/or limits shall be available to the additional insured. Furthermore, the requirement for coverage and limits shall be (1) the minimum coverage and limits specified in this
INSURANCE REQUIREMENTS (City)
March 2021
Agreement, or (2) the broader coverage and maximum limits o f coverage of any insurance policy or proceeds available to the named insured; whichever is greater.
8. The limits of insurance required in this Agreement may be satisfied by a combination of primary and umbrella or excess insurance. Any umbrella or excess insurance shall contain or be endorsed to contain a provision that such coverage shall also apply on a primary and non-contributory basis for the benefit of the City of Petaluma before the City of Petaluma’s own insurance or self-insurance shall be called upon to protect it as a named insured.
E. Acceptability of Insurers
Insurance is to be placed with insurers with a current A.M. Best’s rating of no less than A:VII.
F. Verification of Coverage
NOTE: The City of Petaluma is now using an online insurance program, PINS Advantage. Once you have been awarded a contract with the City of Petaluma, you will receive an e- mail from PINS Advantage/City of Petaluma requesting that you forward the e-mail to your insurance agent(s). Consultant shall furnish the City with Certificate of Insurance along with Declarations and Endorsements effecting coverage required by this clause. The endorsements are to be signed by a person authorized by that insurer to bind coverage on its behalf. All endorsements are to be received and approved by the City before the Services commence.
511 Transit Data Guidelines
Version 2.1
September 30, 2020
METROPOLITAN TRANSPORTATION COMMISSION, SAN FRANCISCO BAY AREA
511 TRANSIT DATA GUIDELINES
P a g e 2 | 24
DOCUMENT VERSION CONTROL
Version No. Date Written/Revised By Objective/ Change
0.1 08/14/2017 Gopi Purohit Initial draft
0.2 08/18/2017 Nisar Ahmed MTC review
0.3 08/25/2017 Deepa Mani, Nisar Ahmed Review of complete draft
1.0 10/12/2017 Todd Kell, Dana McCombs Formatting changes and minor edits
1.0 11/01/2017 Nisar Ahmed, Janet Banner Draft shared internally
1.0 01/17/2018 Nisar Ahmed Addressed Iteris comments from IVR perspective
1.0 02/28/2018 Nisar Ahmed, Brooke
Fotheringham Incorporated transit agency comments
1.0 03/14/2018 Nisar Ahmed Second draft published
1.0 04/16/2018 Nisar Ahmed Version 1.0 published
2.0 12/18/2019 Kapeel Daryani Organizing and removing outdated contents
2.1 09/30/2020 Kapeel Daryani Updated stop_name requirement
511 TRANSIT DATA GUIDELINES
P a g e 3 | 24
TABLE OF CONTENTS
1 PURPOSE ....................................................................................................................................................... 5 2 DOCUMENT OVERVIEW ................................................................................................................................ 5 3 STATIC DATA: GTFS & GTFS+ ......................................................................................................................... 6
3.1 GTFS (Required) ........................................................................................................................................ 6 agency.txt ...................................................................................................................................................... 6 routes.txt ...................................................................................................................................................... 7 calendar.txt ................................................................................................................................................... 8 stops.txt ........................................................................................................................................................ 8 trips.txt .......................................................................................................................................................... 8 stop_times.txt ............................................................................................................................................... 9 fare_attributes.txt......................................................................................................................................... 9
3.2 GTFS (Optional) ...................................................................................................................................... 10 calendar_dates.txt ...................................................................................................................................... 10 fare_rules.txt............................................................................................................................................... 12 shapes.txt .................................................................................................................................................... 12 frequencies.txt (not supported by 511 SF Bay) .......................................................................................... 13 transfers.txt (not supported by 511 SF Bay) ............................................................................................... 13 pathways.txt (supported only in the Regional GTFS feed) ......................................................................... 13 levels.txt (supported only in the Regional GTFS feed) ................................................................................ 13 Feed_info.txt ............................................................................................................................................... 13
3.3 GTFS+ (Required) .................................................................................................................................... 13 directions.txt ............................................................................................................................................... 13 realtime_routes.txt ..................................................................................................................................... 14 calendar_attributes.txt ............................................................................................................................... 14
3.4 GTFS+ (Recommended) .......................................................................................................................... 14 stop_attributes.txt ...................................................................................................................................... 14 rider_categories.txt .................................................................................................................................... 15 fare_rider_categories.txt ............................................................................................................................ 16
3.5 GTFS+ (Optional) .................................................................................................................................... 17 realtime_trips.txt (deprecated) .................................................................................................................. 17 farezone_attributes.txt ............................................................................................................................... 17 4 Real Time Data: GTFS-Realtime .................................................................................................................. 18 Appendix-1: 511 Transit Stop Naming Guidelines .............................................................................................. 19 General Rules .............................................................................................................................................. 19 511 TRANSIT DATA GUIDELINES
P a g e 4 | 24
Roadway Naming in Stop Names ................................................................................................................ 19 Intersection Stop Names............................................................................................................................. 20 Addressed Stop Name ................................................................................................................................ 20 Stops at Landmarks ..................................................................................................................................... 20 Extra Qualifiers in Stop Names ................................................................................................................... 20 Shared and Non-Revenue Stops ................................................................................................................. 20 Special Symbol/Character Quick Reference ............................................................................................... 21 Appendix-2: JMS based Real-Time Transit (RTT) Configuration Data ................................................................. 22
511 TRANSIT DATA GUIDELINES
P a g e 5 | 24
1 PURPOSE
This document is intended to provide a set of guidelines so that MTC’s partner transit agencies can prepare and deliver data as per 511 SF Bay requirements. This document covers both technical data requirements and quality aspects of transit data provided through the General Transit Feed Specification (GTFS), GTFS+ (an extended set of files), and real‐time data feeds in GTFS-Realtime format. Data prepared as per these guidelines will allow the 511 SF Bay transit system to deliver enhanced data to third party consumers that will facilitate better transit travel experience for riders. There are two sections within this document, covering:
• GTFS and GTFS+ static data
• Real-time transit data
2 DOCUMENT OVERVIEW
Transit agencies are requested to use this document as a reference to understand 511 SF Bay transit data requirements. Each section below describes various data elements and their recommended characteristics for data feeds known as GTFS, GTFS+, and real-time.
Additional reference documents that may be consulted, include:
• GTFS reference – specification for GTFS files, available online at https://developers.google.com/transit/gtfs/reference/
• GTFS-Realtime reference – specification for GTFS-Realtime feeds, available online at https://developers.google.com/transit/gtfs-realtime/reference • ‘511 RTT JMS DTD v9.7’ – 511 Real‐Time Transit (RTT) XML DTDs for JMS implementation (deprecated)
511 TRANSIT DATA GUIDELINES
P a g e 6 | 24
3 STATIC DATA: GTFS & GTFS+
The General Transit Feed Specification (GTFS) defines a set of transit data files in comma separated value (CSV) format that together describe a transit service. Data described in these files are considered relatively static in nature. GTFS documentation is available online at the URL mentioned above. While GTFS allows for quite a bit of flexibility, 511 SF Bay Transit implements the GTFS specification with a few additional rules necessary for proper utilization of transit data in a regional setting. These rules don’t break the core GTFS specification; they rather help improve the quality of the data.
In addition to the GTFS files, MTC defines a set of additional CSV files – called the ‘GTFS+’ files – that allow 511 SF Bay Transit to acquire necessary data not covered in the GTFS specification.
For example, GTFS allows for trip direction information in a binary manner (0 for one direction and 1 for the opposite direction). These binary values can only be translated into two default direction names such as ‘Inbound’ and ‘Outbound.’ In a regional system, these default values may not describe directions of all transit services adequately. So, 511 Transit uses the GTFS+ directions.txt file to allow for wide ranging direction names such as ‘North’, ‘Clockwise’, etc.
Some of these additional GTFS+ files may be applicable only for transit agencies providing real- time data to 511 SF Bay, as noted in each file description. GTFS+ files must be included in the same zip package with the standard GTFS files.
Below are 511 SF Bay Transit specific guidelines for various required and optional GTFS files, and specifications for 511 recommended and optional GTFS+ files. Following list provides file categories for GTFS and GTFS+:
• GTFS (Required) – feed is rejected if these files are not provided • GTFS (optional)
• GTFS+ (Required) – feed is rejected if these files are not provided • GTFS+ (Recommended) – feed will not be rejected but the files add significant value to the end user
• GTFS+ (Optional)
3.1 GTFS (REQUIRED)
agency.txt
This is a required file for 511 SF Bay that describes the attributes of a transit service provider.
Table below includes required fields for 511 SF Bay.
Field Name Property/Description Required/Recommended
agency_id
(required)
Value should not exceed 50 characters. Required
agency_name
(required)
Value should not exceed 50 characters. Required
511 TRANSIT DATA GUIDELINES
P a g e 7 | 24
Field Name Property/Description Required/Recommended
agency_url
(required)
Value should not exceed 500 characters. Required
Include a complete and active URL for the transit service website. If the webpage for the service is part of the city’s website, include the full link to the service webpage.
Recommended
routes.txt
In addition to GTFS specifications for the routes.txt file, 511 SF Bay Transit provides the following additional guidelines for route_short_name and route_long_name fields.
Field Name Property/Description Required/Recommended
route_short_name
(required)
Provide the publicly known route identifier. Required
The values in this field are required to be unique. If
values are duplicated, 511 SF Bay Transit will reject the feed.
Required
Values should not contain any description or direction
information such as Inbound, Outbound, E, W, etc.
Recommended
route_long_name
(optional)
This field provides the publicly known additional (to
route_short_name) concise textual name for a route.
The following contents should be avoided in the value of route_long_name.
• route_short_name
• Direction name/code such as ‘inbound’, ‘east’, ‘E’ etc. • Adverb such as ‘to’, ‘from’, ‘towards’, etc.
• The word ‘route’
Required
In order to provide more context on the above guidelines for route_short_name and route_long_name, let’s consider some arbitrary example shown in the following table:
Field Name Not Allowed Acceptable
route_short_name Inbound to 10 NB Fremont Hub 10
Route 14 Eastbound 14
route_long_name Outbound to 6 Downtown Berkeley Downtown Oakland – Downtown Berkeley
Route 38 – Geary Blvd to Sutro Heights Geary Blvd
The route name “Inbound to 10 NB Fremont Hub” provides a lot of details about the route.
Such a complex name that includes line number (10), direction name (Inbound), directional abbreviation (NB), and a destination name (Fremont Hub), can be confusing and should not be used as route_short_name or route_long_name. Instead, only the line number “10” should be used as the route_short_name value. A route_long_name can be the major corridor the route serves (‘Mission’ for route 14 and ‘Geary’ for route 38 of Muni), or be a combination of two endpoints/destinations of the route (‘Downtown Oakland – Downtown Berkeley’ for AC Transit route 6). Direction information should be provided in the GTFS trips.txt file using the direction_id field and be further qualified in the GTFS+ directions.txt file. If “Fremont Hub” is meant to be the destination name, it should be used as the trip_headsign value in the trips.txt file. The GTFS trips.txt file is described in more detail below.
511 TRANSIT DATA GUIDELINES
P a g e 8 | 24
calendar.txt
Agencies should comply with following 511 requirements for calender.txt:
• 511 SF Bay requires that all regular services (Weekday and weekend) be defined in the calendar.txt file.
• 511 Transit also requires that at least one of the days of the week fields (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday) must have its value set to ‘1’ for each service defined in this file.
• Service holidays (no service or reduced service) should only be defined in the calendar_dates.txt file as explained below through use cases. • Each unique service defined in calendar.txt and calendar_dates.txt file should be named in the GTFS+ calendar_attributes.txt file.
stops.txt
A set of 511 SF Bay specific guidelines for this required GTFS file are provided below.
Field Name Property/Description Required/Recommended
stop_code
(required for real-
time agencies)
For agencies providing real-time data to 511 SF
Bay, values in this field must be the same as the
real-time stop IDs.
Required
For agencies providing real-time data to 511 SF
Bay, values in this field must be prepended with
MTC assigned prefix digit(s). Prefixed values
ensure uniqueness of stop codes across the
region and facilitates departure information
inquiry.
Required
Values should be kept to a minimum number of
digits (preferably no more than 6 digits) for
better usability.
Recommended
stop_name
(required)
Length of the stop_name values should be no
more than 100 characters.
Required
Agency name, direction or route information
should not be a part of the stop name.
Required
Stop names should be developed as per the
guidelines provided in Appendix-1. This will help
improve the quality of stop names and build data
consistency across the region.
Required
wheelchair_boarding
(optional)
This information helps application developers
provide more useful information to riders with
special needs.
Recommended
trips.txt
A set of 511 SF Bay specific guidelines for this required GTFS file are provided below.
Field Name Property/Description Required/Recommended
trip_headsign
(Required)
Though optional in GTFS specification, this field adds
significant value for data consumers. The value should
Required
511 TRANSIT DATA GUIDELINES
P a g e 9 | 24
Field Name Property/Description Required/Recommended
be concise and provide a meaningful destination name
for the trip.
Value should not exceed 120 characters. Required
trip_short_name
(optional)
Though optional, this field is important for those
services that publish vehicle numbers such as the train number.
Recommended for appropriate
service
Value should not exceed 50 characters. Required
direction_id
(required)
This value, along with its description in the GTFS+
directions.txt file, is required by 511 SF Bay.
Required
wheelchair_accessible
(optional)
This optional GTFS field adds valuable information for
riders with special needs. 511 encourages transit
agencies to provide this value.
Recommended
bikes_allowed
(optional)
This optional GTFS field adds valuable information for
riders with bike. 511 encourages transit agencies to
provide this value.
Recommended
stop_times.txt
A set of 511 SF Bay specific guidelines for this required GTFS file are provided below. • Timepoint stops must be clearly identified, either by providing arrival and departure times only for timepoint stops, or by marking timepoint stops with the value ‘1’ in the timepoint field when all stops have arrival and departure times. Without timepoint identification, information providers consider every stop with arrival and departure time a timepoint. This will result in user-unfriendly timetable output. • First and last stops for each trip must be timepoints. • Non-revenue stops must not be included.
• A timepoint stop must include both arrival and departure times.
fare_attributes.txt
511 SF Bay requires the fare_attributes.txt file. Without this file, an important piece of information about a transit trip will be missing. This file should include all current and future general fares for single ride, route based, or zone based. For example, if the current single adult fare is $2.00 and increases to $2.50 from a particular date, both fares should be included in this file, as shown with fare IDs 1 and 4, respectively, in Figure 1 below.
Figure 1: fare_attributes file with current and new fares Fares expiring on December 31, 2017
Fares starting on January 1, 2018
511 TRANSIT DATA GUIDELINES
P a g e 10 | 24
In the GTFS+ fare_rider_categories.txt file, the $2.00 fare should be identified with an expiration date of December 31, 2017, and the $2.50 fare should be identified with a commencement date of January 1, 2018, as demonstrated in the example GTFS+ fare_rider_categories.txt file below.
This approach with expiration and commencement dates allows for codifying fare change without recreating the GTFS feed or duplicating routes only to accommodate a fare change. This approach for fare change allows to maintain the GTFS specification for the fare_attributes.txt file.
3.2 GTFS (OPTIONAL)
calendar_dates.txt
511 SF Bay uses the calendar_dates.txt file only for special service and service exceptions such as Holiday service. Regular service should only be defined in the calendar.txt file. If calendar_dates.txt file is missing in the feed, 511 SF Bay assumes there are no service exceptions to the regular service. No more than 150 (one hundred and fifty) unique dates should be included in this file. When more than 150 unique dates are necessary, it is recommended that those dates be split over multiple feeds. Calendar_dates.txt can be used for various service exception use cases. The three most common ones are explained with examples below.
Use Case 1: No Service Holiday
Let’s consider the Christmas and New Year's holidays, both falling on Mondays. The agency doesn’t run any service on those days. In the calendar.txt file, the agency defined three different regular services – for weekdays, Saturday, and Sunday. Because, Christmas and New Year’s fall on weekdays, the agency will define one service exception for each in the calendar_dates.txt file to remove the weekday service for December 25, 2017 and January 1, 2018 by using the exception_type ‘2,’ as demonstrated in the calendar.txt and calendar_dates.txt files below.
Figure 2: calendar.txt file with regular service
511 TRANSIT DATA GUIDELINES
P a g e 11 | 24
Figure 3: calendar_dates.txt file for no service
Use Case 2: Service Swap for a Holiday
Let’s consider the same Christmas and New Year’s holidays, but this time the agency runs Sunday service instead of the weekday service for both holidays. The calendar.txt file will remain the same, but the calendar_dates.txt file will have one additional definition for each holiday to specify the addition of the Sunday service, in addition to the removal of the weekday service. See the example calendar_dates.txt file below in combination with the calendar file in figure 4.
Figure 4: calendar_dates.txt file for service swap
Use Case 3: Special Service
Now let’s consider a scenario when additional trips are added to the service for November 15, 2017 – a Wednesday – to a few routes to accommodate the extra passenger load expected for the baseball game. The service that captures only the extra trips will be defined in the calendar_dates.txt file with exception_type ‘1’, as demonstrated in figure 5 below.
Figure 5: calendar_dates.txt file with extra service for baseball game
511 TRANSIT DATA GUIDELINES
P a g e 12 | 24
Alternatively, if the baseball game day service includes all trips of that day, it can be added in the calendar_dates.txt file replacing the regular weekday service, as shown in the figure 6 below.
Figure 6: calendar_dates.txt file with special service replacing regular service
fare_rules.txt
The fare_rules.txt file is optional and can only be included with an accompanying fare_attributes.txt file. Figure 7 below is an example fare_rules file that should accompany the fare_attributes file in Figure 1. This file says that fare_id 1 (referred from fare_attributes file) applies to route_ids 2, 4, 6, 8, 1, 3, 5, 7, and 9 (referred from routes.txt file). Similarly, fare_id 2 applies to route_ids 41 and 42, and fare_id 3 applies to route_ids 33, 31, and 30.
Figure 7: fare_rules file for current fares
shapes.txt
When provided, 511 SF Bay processes the file and provides to data consumers.
511 TRANSIT DATA GUIDELINES
P a g e 13 | 24
frequencies.txt (not supported by 511 SF Bay)
511 SF Bay currently doesn’t support this file. Instead, arrival/departure schedules should be provided in stop_times.txt file (described above) for all trips in the service.
transfers.txt (not supported by 511 SF Bay)
511 SF Bay currently doesn’t support this file. If provided, this file will be discarded by the system.
pathways.txt (supported only in the Regional GTFS feed) 511 SF Bay currently doesn’t process this file if included in the transit agency GTFS feed.
Instead, 511 SF Bay creates and includes pathways.txt file for the entire region in a single Regional GTFS feed.
levels.txt (supported only in the Regional GTFS feed)
511 SF Bay currently doesn’t process this file if included in the transit agency GTFS feed.
Instead, 511 SF Bay creates and includes levels.txt file for the entire region in a single Regional GTFS feed.
Feed_info.txt
511 SF Bay includes its own feed_info.txt file in the output GTFS feed. If provided in the transit agency GTFS feed, this file will be discarded by the system.
3.3 GTFS+ (REQUIRED)
directions.txt
The binary (0 or 1) values allowed for the direction_id field in the GTFS trips.txt file don’t allow for custom, more informative, direction names such as North, South, etc. This additional file captures the direction text for each of the directions in a route and assigns them to timetable outputs. 511 SF Bay strongly recommends that this file be provided. Without the direction names, timetable outputs will include default ‘inbound’ and ‘outbound’ direction names. When this file is provided, the optional direction_id field in GTFS trips.txt must be filled in, and the following guidelines should be adhered to for this file.
Field Name Property/Description Required/Recommended
route_id
(required)
This value is referenced from the GTFS routes.txt file. Required direction_id
(required)
This value is referenced from the GTFS trips.txt file.
Each (route_id, direction_id) pair should only appear
once.
Required
direction
(required)
Values allowed include: Required
North
South
East
West
Northwest
Southeast
Southwest
Clockwise
Inbound
Outbound
Loop
A Loop
511 TRANSIT DATA GUIDELINES
P a g e 14 | 24
Field Name Property/Description Required/Recommended
Northeast Counterclockwise B Loop
realtime_routes.txt
This additional file contains information about routes that are real-time enabled. It is a required file for agencies providing a real-time feed to 511 SF Bay. This file allows 511 SF Bay to identify routes that are and aren’t enabled for real-time predictions. Identification of real-time enabled routes allows 511 SF Bay to use GTFS/GTFS+ data as the service configuration data for the real- time data. When included, this file should comply with the following guidelines.
Field Name Property/Description Required/Recommended
route_id
(required)
This value in referenced from the routes.txt file. Required realtime_enabled
(required)
Allowable numeric values:
0 – route is not real-time enabled
1 – route is real-time enabled
Required
calendar_attributes.txt
Though not part of the GTFS specification, this additional file provides descriptive names for all unique services defined in the GTFS calendar.txt and calendar_dates.txt files. Names for services provided through the service_description field are important for applications as they are used for naming service types in the display of timetables and user interfaces. Names help users look up the desired timetable. Inclusion of this file is recommended. All unique service_ids defined in the GTFS calendar.txt and calendar_dates.txt files must be described in this file.
Field Name Property/Description Required/Recommended
service_id
(required)
Values must match with all unique service_ids from
calendar.txt and calendar_dates.txt.
Required
service_description
(required)
Length should not exceed 250 characters. Required
Should convey the correct description of the
service, e.g., Weekdays, Sunday/Holiday, Weekday
except Wednesday, Wednesday Only, etc. For
service running on specific days of the week, e.g.,
Monday, Wednesday, and Friday, use description
like ‘Mon, Wed, Fri’ instead of MoWeFr.
Recommended
3.4 GTFS+ (RECOMMENDED)
stop_attributes.txt
This additional file helps to capture important stop attributes that are not included in GTFS stops.txt file. This additional data enriches stop information and is useful for better journey planning. When this recommended file is included, the following guidelines should be adhered to. When provided, 511 SF Bay will include this file for the data consumers.
511 TRANSIT DATA GUIDELINES
P a g e 15 | 24
Field Name Property/Description Required/Recommended
stop_id
(required)
This value is referenced from the GTFS stops.txt file. Required accessibility_id
(optional)
Allowable numeric values and their meaning: Recommended 0 - Unknown
1 - No ADA
2 - Full ADA
3 - Wheel
Chair
4 - Blind
5 - Deaf
6 - Blind/Wheel Chair
7 - Deaf/Blind
8 - Deaf/Wheel Chair
cardinal_direction
(optional)
Allowable two-character values and their full names:
NO - North SO - South EA - East WE - West
NE -
Northeast
NW -
Northwest
SE -
Southeast
SW - Southwest
Recommended
relative_position
(optional)
Allowable two-character values and their meaning:
• NS = nearside of intersection
• FS = far side of intersection
• AT = stop is at a landmark used in the stop name
• OP = stop is across street from the landmark used in the stop name
• MB = stop somewhere near the middle of the street segment Recommended
stop_city
(required)
Helps to look up stops in a city when spatial query is not possible.
Length should not exceed 60 characters.
Required
rider_categories.txt
GTFS fare_attributes.txt file can only provide regular adult fare. Fares applicable for other rider categories such as students, children, seniors, etc. can be provided through this additional GTFS+ rider_categories.txt file in combination with the GTFS+ fare_rider_categories.txt file. 511 SF Bay recommends that transit agencies include both rider_categories.txt and fare_rider_categories.txt files when there are discounted fares for special rider categories. The rider_categories.txt file defines various rider categories a transit agency may have.
When provided, the file should comply with the following guidelines.
Field Name Property/Description Required/Recommended
rider_category_id
(required)
Must use following numeric IDs: Required
1 – Regular (adult)
2 – Senior
3 – Child
4 – Student
5 – Youth
6 – Disabled
7 – Promotional
11 – Military
15 to 25 – Custom categories
(agency can assign categories
that do not fall under
standard categories
mentioned above)
rider_category_description
(required)
Length should not exceed 256 characters. Required
Should be easily understandable, e.g., ‘Child (ages 5-
11)’, ‘Seniors (Ages 62 & Up)’, etc.
Recommended
Figure 8 below provides a sample rider_categories.txt file. 511 TRANSIT DATA GUIDELINES
P a g e 16 | 24
Figure 8: rider_categories file with three non-regular rider categories
fare_rider_categories.txt
The purpose of this file is two-fold. It specifies fare attributes for various rider categories defined in the rider_categories.txt file. It also facilitates fare change information – with or without rider categories.
GTFS file fare_attributes.txt can contain current and future fare prices for the ‘Regular (adult)’ rider category but it cannot specify when a fare ends, and a new fare begins. Expiration dates of the current regular fare and commencement of the future regular fare are defined in this additional GTFS+ fare_rider_categories.txt file. In addition, current and future fares for other non-regular rider categories can be provided in this file.
Field Name Property/Description Required/Recommended
fare_id
(required)
For regular adult fares, this value is referenced from the fare_attributes.txt file. If fare change is not included, regular adult fare_id should not be included.
Required
For non-regular fares, new and unique values are introduced. Required rider_category_id
(required)
This value is referenced from the rider_categories.txt file. Required Each (fare_id, rider_category_id) pair can only appear once in this file.
Required
Price
(required)
Values must be provided for all non-regular rider categories. Required Format of price values should be 5,2 (numbers up to and including 999.99) decimal number.
Required
Currency type is assumed to be the same as the
fare_attributes.txt file.
Required
expiration_date
(optional)
Must be defined for all expiring fares (fares expire at the end of the service day); Empty for all upcoming fares.
Required
Values must be provided in the YYYYMMDD format. Required commencement_date
(optional)
Must be defined for all upcoming fares (fares begin at the start of the service day); Empty for all expiring fares.
Required
Values must be provided in the YYYYMMDD format. Required
Figure 9 below provides a sample fare_rider_categories.txt file that captures regular fares defined in the fare_attributes.txt file and fares for non-regular rider categories defined in the rider_categories.txt file with appropriate expiration and commencement dates.
511 TRANSIT DATA GUIDELINES
P a g e 17 | 24
Figure 9: fare_rider_categories file with expiration and commencement dates for fares
3.5 GTFS+ (OPTIONAL)
realtime_trips.txt (deprecated)
This file is relevant for agencies providing real-time data to 511 SF Bay. It helps map trip IDs between GTFS and real-time feeds. If trip IDs in the GTFS trips.txt file and in the real-time feed are the same, this file should not be included. 511 SF Bay prefers that the trip IDs in the real- time data feed are the same in the GTFS trips.txt file. If that is not possible for any reason, this realtime_trips.txt file must be provided, complying with the following guidelines.
Field Name Property/Description Required/Recommended
trip_id
(required)
This value is referenced from the GTFS trips.txt file. Required realtime_trip_id
(required)
This value is referenced from the real-time configuration TripMapping.
Required
farezone_attributes.txt
This additional GTFS+ file is optional and applicable only for those transit services that use zone- based fares. This file facilitates naming fare zones to help riders find fares for their journey from a fare lookup tool. For example, AC Transit may name its fare zones as Local and Transbay, or East Bay and Transbay.
Field Name Property/Description Required/Recommended
zone_id This value is referenced from the stops.txt file. Required
511 TRANSIT DATA GUIDELINES
P a g e 18 | 24
Field Name Property/Description Required/Recommended
(required)
zone_name
(required)
Length of the value should not exceed 250 characters. Required
4 REAL TIME DATA: GTFS-REALTIME
Google Transit Feed Specification for Real Time is an extension to the GTFS static. It provides up to date information for the current arrival and departure times. 511 is introducing GTFS-RT as the preferred format for real time data. GTFS-RT feed uses protocol buffers for the data exchange that keeps the data in a simple and light weight format for faster transmission.
Currently, three GTFS-RT feeds are supported by 511 SF Bay. Following is the list of feeds with additional (if any) 511 SF Bay requirements.
1. Trip Updates: Transit agencies shall provide the data as per the GTFS-Realtime specification with the following additional requirements:
o stop_id values must be included in the stop_time_update field (StopTimeUpdate message) even if the stop_sequence is included.
o For arrival or departure field values in the StopTimeEvent message agencies must provide absolute ‘time’ value even if ‘delay’ value is provided.
2. Vehicle Positions: Standard GTFS-Realtime specification requirements only
3. Service Alerts: Standard GTFS-Realtime specification requirements only
511 has deprecated and gradually phasing out its JMS based real time and configuration data feeds. The specification of the deprecated JMS configuration data is still available in Appendix 2 for agencies that have not migrated to GTFS-Realtime.
511 TRANSIT DATA GUIDELINES
P a g e 19 | 24
APPENDIX-1: 511 TRANSIT STOP NAMING GUIDELINES
General Rules
1. Easy to understand: Stop names distributed for public consumption should reflect the names that people will understand in the local and tourist vernacular. If a non-public name is necessary for operational purpose, such non-public name may be maintained in the inventory in a separate field. For example, the operational name ‘Green Division Yard’ for SFMTA’s ‘Balboa Park Station’ stop should be maintained in a non-public field and not be disseminated in the public GTFS feed.
2. Standard font: All stop names should be maintained in one standardized case, preferably the Title Case, where only the initial letter of principal words is capitalized, e.g. Market Street. Exception may be provided to names with vernacular usage such as ‘MacArthur Blvd’ or ‘da Vince’. The exceptions take precedence over the general rule.
3. Period (.) should be avoided in stop names unless necessary for situation such as a landmark name that includes the period. For example, ‘O.com Coliseum’.
4. Associative terms: When stop names are constructed with two distinct non-addressed elements such as two intersecting streets (‘Main St’ and ‘A St’) or a street and a landmark (‘Main St’ and ‘Park N Ride’), only ‘and’, ‘@’, ‘&’, or ‘+’ with spaces before and after can be used to associate those elements together in a stop name. More than two elements in a stop name should be avoided.
5. None of the associative terms/symbols can be used for any other purposes in stop names than for the purpose of separating street names in an intersection stop name.
6. Word ‘at’ and symbol ‘/’ should not be used as associative term/symbol between two distinct elements of a stop name.
7. Hyphen and space: Where a hyphen is suggested in this document for stop names it should be used without a space before and after the hyphen.
8. Avoid directions: Route direction information should not be included in stop names. For example, parenthetical ‘Westbound’ in ‘Alida Way & Rotary Plaza (Westbound)’ should not be used.
9. Avoid pick-up/drop-off: Pick-up/drop-off information should not be included in stop names. It is generally maintained and provided as separate attributes in the GTFS stop_times.txt file.
10. Nearside & Farside:‘Nearside’ and ‘farside’ should not be included in stop names. This information should be provided through the GTFS+ stop_attributes.txt file.
Roadway Naming in Stop Names
11. Lengthy street names: The name portion of a full street name should not be abbreviated. However, if the street is popularly known by its abbreviated version, e.g., ‘MLK’ for ‘Martin Luther King’, then abbreviated version may be used as the primary stop name.
12. Street suffix/type (Ave, St, Pkwy, etc.), and pre- and post-directional (N, E, NW, etc.) elements of street name should either be fully spelled out or be abbreviated as per the standards set in Appendices B and C of the USPS publication http://pe.usps.gov/cpim/ftp/pubs/Pub28/pub28.pdf .
Complying with USPS standard allows for consistent use these elements across the region. When abbreviated, period (.) should be avoided.
13. Freeways and highways used in stop names should be named with their abbreviated (USPS standardized abbreviation) designation followed by the highway number. For example, ‘I 280’ or ‘Hwy 280.’ The hyphen, e.g., in ‘I-280’, must be avoided and highway names should NEVER start with the highway number (e.g., ‘280 Hwy’ is not allowed.)
14. No hyphenation: Hyphenated street name must be avoided in stop names, even if that is how the street is named. For example, ‘Alvarado-Niles Rd’ should be ‘Alvarado Niles Rd’ in stop names.
511 TRANSIT DATA GUIDELINES
P a g e 20 | 24
Intersection Stop Names
15. On-street stop: In case of stops at intersection locations, the on-street should always be the first street name in the stop name, then an associative term (see rule #4 above), followed by the at-street name.
16. A single associative term should be used consistently throughout the entire stop inventory of the same transit agency.
17. Associative terms/symbols should ONLY be used for separating street names in an intersection stop name. All associative terms/symbols should be avoided for purposes other than associating two non- addressed elements of a stop name. Alternative style should be used for non-associative purposes.
For example, stop names such as ‘Main Street & Park & Ride’ or ‘Hilltop Park & Ride’ can be ‘Main Street & Park N Ride’ or ‘Hilltop Park N Ride’.
18. For stop names at intersections where streets have different names on either side of the road on which the bus is traveling, the name of the additional ON/AT street should be included using a forward slash (/). Consider example ‘Decoto Rd & Royal Ann Dr/Clover St’ or ‘Decoto Rd & Clover St/ Royal Ann Dr’. Notice that in the first example name, the ‘Royal Ann Dr’ appears before the (/) because the stop is on the ‘Royal Ann’ side of Decoto Rd at the intersection. Similarly, in the second example, ‘Clover St’ appears before the (/) because the stop is on the Clover St side of Decoto Rd at the intersection.
Addressed Stop Name
19. Stop names with a numbered address should always begin with the address number. A stop at 123 Main St should be named as ‘123 Main St’, not as ‘Main St at 123.’ Stop names other than the numbered address should NEVER start with a number.
20. The stops that are not at an intersection but identified using a well-known landmark should ideally be named using the numbered address of the stop location. For example, ‘Fitzgerald Ave at Sizzler’ should be renamed to ‘3483 Fitzgerald Ave’. If the landmark must be included, the stop can be named as either ‘3483 Fitzgerald Ave at Sizzler’ or ‘Fitzgerald Ave @ Sizzler’.
21. Stop names like ‘Gurdwara Cul-de-sac’ should be avoided. A better option would be the address on Gurdwara Rd ‘251 Gurdwara Rd’ or ‘Gurdwara Sahib Fremont’.
Stops at Landmarks
22. Stop names at landmarks/known places should be fully qualified. For example, ‘San Carlos Caltrain Station’ is preferred over ‘San Carlos Caltrain’ or ‘San Carlos Station’ unless the shorter version is more popular in the local vernacular.
23. When a stop is located within a larger known place/area the stop name should start with the larger place/area name followed by more specific location name appended with either a hyphen or ‘at.’ For example, ‘University of California Berkeley-Business School’, ‘College of San Mateo at CSM Dr’, ‘Southland Mall at Macy’s, ‘Millbrae Bart-Bay 5’, or ‘South San Francisco Bart-Bay 7 Eastside.’
24. A period may be used if it is part of the landmark name. For example, ‘O.com Coliseum’.
Extra Qualifiers in Stop Names
25. Extra qualifying information in a stop name such as ‘overpass’ in ‘Ralston Ave & Hwy 101 overpass’ should be hyphenated as ‘Ralston Ave & Hwy 101-Overpass.’ Another example is ‘El Camino Real & Alta Loma-Stairway’ or ‘Hwy 1 & Hwy 35-Bus Pad’.
Shared and Non-Revenue Stops
26. If transit agencies share a physical stop location, it is preferred that the stop name be the same in the stop inventories of all agencies sharing that stop. This helps with regional information dissemination. 511 TRANSIT DATA GUIDELINES
P a g e 21 | 24
27. Non-revenue/non-public stops should not be included in the GTFS stops.txt file.
Special Symbol/Character Quick Reference
The table below provides a quick reference chart for various symbols and terms mentioned in this stop naming guidelines, and their usage.
Symbol/Term Usage Rules Examples
and • Only to be used as the associative term in a
stop name with two distinct non-addressed
elements.
• Spaces should be included before and after.
• Allowed: A St and Main St
• Allowed: Ardenwood Ter and Ardenwood Park N
Ride
@ • Only to be used as the associative term in a
stop name with two distinct non-addressed
elements.
• Spaces should be included before and after.
• Allowed: A St @ Main St
• Allowed: Ardenwood Ter @ Sizzler
& • Only to be used as the associative term in a
stop name with two distinct non-addressed
elements.
• Spaces should be included before and after.
• Allowed: Fremont Blvd & Decoto Rd
+ • Only to be used as the associative term in a
stop name with two distinct non-addressed
elements.
• Spaces should be included before and after.
• Allowed: Geary Blvd + 33rd Ave
/ • To be used without spaces for joining names
of a street with two different names at an
intersection.
• Not to be used as the associative term for two
distinct elements of a stop name.
• Allowed: Decoto Rd and Royal Ann Dr/Clover St
• Not allowed: Geary Blvd/33rd Ave
at • Not to be used as the associative term for two
distinct non-addressed elements of a stop
name.
• Allowed: 456 Myra St at City Hall, College of San
Mateo at CSM Dr
• Not allowed: Myra St at Capital Ave
.
(period)
• Should be avoided with abbreviation or to end
a stop name.
• Can be used if it is part of the name (rule #25).
• Allowed: O.co Coliseum
• Not allowed: Wabash Rive Pl. and Santee Rd.,
Wabash Rive Pl and Santee Rd.
-
(hyphen)
• To be used with additional qualifying
information in a stop name (rule #11). When
used, space before or after should be avoided.
• To be avoided in highway names.
• To be avoided in street names.
• Allowed: El Camino Real & Oak Grove Ave-Menlo
Park, University of California Berkeley-Business
School
• Not allowed: I-280, Alvarado-Niles Blvd
511 TRANSIT DATA GUIDELINES
P a g e 22 | 24
APPENDIX-2: JMS BASED REAL-TIME TRANSIT (RTT)
CONFIGURATION DATA
This section of the document provides further explanation for data elements and their attributes defined for Real–Time Transit Configuration dataset in the “Extensible Markup Language (XML) Document Type Definitions (DTDs) for Java Message Service (JMS) Implementation”, version 9.7. Transit service configuration data can be described based on route directions or trips. 511 Transit requires that the configuration data be provided with trip definition provided through the TripMapping elements in the TripMappingData collection. The following table provides requirement details for all data elements and their attributes included in the configuration dataset.
When an agency provides a GTFS-Realtime feed (see
https://developers.google.com/transit/gtfs-realtime/reference/ for technical references on feed entities, TripUpdate, VehiclePosition, and Alert), this section is no longer relevant for that agency because real-time data will not be collected in the JMS XML protocol.
Data Element Attribute Description and Guidelines
TripMappingData
(required)
• This XML collection holds all trip mapping elements of the configuration dataset. 511 Transit requires that transit agencies provide configuration data using this data collection.
agency
(required)
• Length of the agency value should be no more than 50
characters.
• The value for this attribute is set and provided by 511 Transit when the JMS communication parameters are established.
version
(required)
• Value must be numeric such as 1.0. It can be fixed, or it may change as a new feed version is produced, but the version in the configuration dataset must match with the corresponding prediction and arrival status datasets.
TimeStamp
(required)
• The date/time of the current snapshot of the configuration dataset.
• The format of the timestamp should be
• YYYY-MM-DDTHH:MM: SSZ where Z = (+/-) HH:MM
• The year, month, and day are specified, followed by a “T” (for Time) and then the hours, minutes, and seconds, followed by a time zone indicator. Note that the time in hours is specified on a 24-hour clock; i.e., am and pm cannot be used. For the timezone “Z”, indicate the difference from UTC in the format: (+/-) HH:
MM.
• Ex: 2017-07-05T14:15:47-07:00
TripMapping
(required)
• Each of these elements defines a single trip in the service. At a minimum, values for tripID, routeKey, dirKey, and dirTitle attributes should be provided.
tripID
(required)
• Identifies a vehicle trip in the transit service and must match with the trip_id in GTFS file trips.txt or realtime_trip_id in GTFS+ realtime_trips.txt file for the same vehicle trip.
• Values of tripIDs must be unique within a TripMappingData collection.
511 TRANSIT DATA GUIDELINES
P a g e 23 | 24
Data Element Attribute Description and Guidelines
routeKey
(required)
• Identifies a route by its publicly known identifier.
• Values of routeKey must match with values of route_short_name in GTFS routes.txt file for the same transit route.
dirKey
(required)
• Ideally, dirKey should provide a generic direction code for all trips heading in the same direction of travel irrespective of their pattern designation. Values should match with values provided in the direction field of the GTFS+ directions.txt file. • Alternatively, if patterns are to be separately identified in each direction, dirKey values should uniquely identify them with values such as 'west1' 'inbound2', etc.
• Values of dirKey should not include route number or name or single letter direction code (E). For example, "30E
Vacaville/Davis" should be avoided as dirKey value. Instead, simply ‘East’ should be used.
dirTitle
(required)
• This attribute provides a textual name for the route direction and is very helpful for transit riders.
• If single dirKey is defined for all trips irrespective of the pattern designation, a single dirTitle value should also be used for all trips in the same direction.
• Length of the dirTitle values should be no more than 120 characters.
• These attribute values can be the trip_headsign values provided in the GTFS trips.txt file.
• dirTitle value should not be duplicated as dirKey value. • The following rules should be adhered to for dirTitle value:
• Values of dirTitle should not contain route number or name.
For example, it should be “Inverness”, not “30 Inverness.” • No directional information should be included. For example, instead of “Outbound to Downtown Berkeley” or “North (or N) to Downtown Berkeley” it should be “Downtown
Berkeley.”
• If a single dirKey is used for trips in the same direction, the destination name for the pattern with the most trips can be used for dirTitle.
• Values of dirTitle should not include special character such as ‘|’ (pipe).
• Values should not include words such as ‘to’, ‘toward’, etc.’ defaultTripForRouteDir
(optional)
• Identifies a trip as the most prevalent trip in a direction.
ConfigurationData • A collection of route elements.
numStops
(required)
• Identifies the total number of unique stops.
msg
(optional)
• Provides special message that may be applicable for the configuration data. For example, “This version contains special services for the Bay to Breakers.”
agency
(required)
• Same value as provided in the TripMappingData.
version
(required)
• Same value as provided in the TripMappingData.
TimeStamp
(required)
• Same value as provided in the TripMappingData.
511 TRANSIT DATA GUIDELINES
P a g e 24 | 24
Data Element Attribute Description and Guidelines
Route • An element that defines attributes of a route and collection of stops for trips defined as TripMapping element.
• Each Route element must contain route Key and title
attributes, and a collection of Direction elements.
key
(required)
• Value must match with the route_short_name value in the GTFS routes.txt file.
title
(required)
• Name of the route should be a short name that might be in use as public information along with route number/code
provided in the key field. If such a name is not applicable, the same value used in the key field may be duplicated in this field.
• If route_long_name value is provided in the GTFS routes.txt file, the same value should be used here.
• Route direction information must be avoided as a part of this attribute.
Direction • Though named ‘Direction,’ it actually identifies a collection of stop elements for a trip defined as a TripMapping
element under the TripMappingData.
key
(required)
• Value referenced from tripID in TripMapping.
title
(required)
• Value referenced from dirTitle in TripMapping.
dirType
(required)
• When dataset is provided with the XML collection
TripMappingData , dirType value is “TRIP_ID.”
Stop • An element that defines a stop within a trip.
• Every stop element must include stop key, title, and
stopOrder.
key
(required)
• Values of stop key must match with the stop_code value in GTFS stops.txt file for the same stop.
• As required for the GTFS stop_code, this value must include the MTC assigned prefix digits assigned for the transit agency.
• Length should be kept to six or fewer digits.
title
(required)
• Same set of rules defined for the stop_name field in the GTFS stops.txt file applies to this attribute.
• Direction and/or route information should not be a part of the stop title.
• Detailed guidelines for stop title are provided in Appendix-1. stopOrder
(required)
• Sequence of the stop within the trip.
• Value can start from ‘0’ or ‘1.’