The file's text, extracted by GovTribe without its formatting.
| Event ID: 0000032011 | Q & A Set #1 |
| GTFS-Realtime Services RFP | August 6, 2024 |
| Item |
| Proposer Question |
| State’s Response |
| Change to RFP (Yes/No) |
| 1. |
| Text: Reporting all identified Service Unavailability Events and Journey Planning Application Events, including those resulting from Exclusion Events, to the Transit Provider within an hour of identification, with reference to the unique and trackable ID numbers if an associated customer support inquiry was created. |
Question: The text and details should be specified in more detail and examples be provided to better understand the intended requirements.
| Not applicable as this is not a question. |
| No. |
| 2. |
| Text: The level of detail, including the need for additional report(s), and the format of these report(s) shall be defined in the User Agreement. |
Question: Better to clarify what reports shall be included. Leaving details for the user Agreement without having a chance to modify the prices set in the rate sheet, is putting the contractor at risk.
| Not applicable as this is not a question. |
| No. |
| 3. |
| In the case of any event/tender documentation being updated, or requirements changed, or answers to questions being provided, how will event participants/bidders be informed about such changes? |
| All changes will be made as an addendum to the RFP that is posted under the Event ID #0000032011 on the CaleProcure website. Vendors must be registered with CaleProcure to receive bid notifications. |
| No. |
| 4. |
| Can the State please provide a recording of the Bidder’s Conference? |
| The bid conference was not recorded. |
| No. |
| 5. |
| How would the State like Bidders to submit proposed redlines to the terms and conditions? |
| The State is not accepting redlines to the terms and conditions. |
| No. |
| 6. |
| Would it be possible for you to send us the presentation slides (if any) from the bidders' conference and a list of attendees? |
| The State is not able to provide the presentation slides from the bid conference. |
The list of attendees is below:
Lynnell Cuthbertson-DGS Melissa Loscher-DGS Kyle Archer-Passio Technologies Olaf-Not indicated Chris Breyfogle-Passio Technologies Magnus Stahlberg-Not indicated No.
| 7. |
| The State’s requirement for Contractor’s to bill Transit Providers monthly (or longer) in arrears (Exhibit B, Item 4, Payment), coupled with the FTA’s Termination for Convenience clause (Exhibit G, Section 1.5), effectively makes the contracts executed off this MSA monthly commitments (rather than a 3 year contract with 2 optional years as outlined in the RFP). Is the State willing to change the payment structure such that Contractors will be able to invoice annually in advance with Transit Providers? Further, can the termination for convenience be removed altogether, allowing the Transit Provider to negotiate whether that is required based on FTA funding? |
| No. |
| No. |
| 8. |
| What are the main criteria you will use to evaluate potential vendors for this project? |
| Please see RFP Section 6 - Evaluation |
| No. |
| 9. |
| Is there a current GTFS-Realtime solution in place? If so, can you provide details on the existing system and its performance? |
| No. |
| No. |
| 10. |
| Can the billing terms and structure be negotiated with individual transit operators? |
| As specified in RFP Attachment 7, Exhibit B, Section 4 Payments, the Contractor and Transit Provider may agree on a less frequent invoicing cycle (e.g., quarterly), as specified in the User Agreement. |
| No. |
| 11. |
| What are the criteria for executing User Agreements with local governmental transit agencies, and how will these agreements be managed and monitored? |
| Please see the following sections in RFP Attachment 7, Exhibit A: |
Section 3, Contract Administration, Section 4, Authorization to Render Services, and Section 8 MSA Usage Report.
No.
| 12. |
| What level of customer support and service management is expected, particularly in terms of response times and issue resolution? |
| Levels of Customer Support are defined in Attachment 7, Exhibit A.1., Section 3. Response times for all customer support platforms are defined in Attachment 7, Exhibit A.1, Section 3.2. |
| No |
| 13. |
| Could you provide more details on the specific data accuracy and reliability expectations for the GTFS-Realtime Feeds? |
| Feed accuracy metrics are defined in Attachment 7, Exhibit A.1., Section 1.1.3. At a minimum, the GTFS-Realtime Feeds shall: Be consistent with the GTFS Schedule Feed provided by and published by the Transit Provider for the trip_id, vehicle_id, route_id, and stop_id, as described in Attachment 7, Exhibit A.1., Section 1.1.1.5. The Contractor is responsible for ensuring the accuracy of association between the GTFS Schedule Feed and the GTFS-Realtime Feeds, as described in Attachment 7, Exhibit A.1., Section 1.1.1.5. The Contractor is expected to provide GTFS-Realtime Services that have a Service Availability of greater than or equal to 99.9%, as described in Attachment 7, Exhibit A.2., Section 2.1. |
| No. |
| 14. |
| Are there any anticipated changes or updates to the GTFS-Realtime Standards during the contract period that we should be aware of? |
| The GTFS Standard is an open standard that is designed to be changed and is largely backwards-compatible. It is expected that changes or updates would occur during the contract period, and Mobility Data-led planned major changes can be found in the Mobility Data Work Plan. The Contractor is responsible for incorporating new, formally adopted required changes to the GTFS-Realtime Standard within thirty (30) calendar days of adoption, as defined in Attachment 7, Exhibit A.1., Section 1.1.1.3. |
| No. |
| 15. |
| Can you elaborate on the supplemental requirements for on-vehicle devices being certified on all five networks? |
| Ability to transmit location data via a minimum of built-in 4G LTE mobile connectivity is a minimum requirement, as defined in Attachment 7, Exhibit A.3., Table 1, Item No. 4. This capability is demonstrated in the vendor response through certification on the four required networks: AT&T, FirstNet, T-Mobile, and Verizon. |
| No. |
| 16. |
| What are the expected timelines for the deployment and certification of on-vehicle devices across the transit agencies? |
| If awarded an MSA, timelines for deployment will be agreed upon in the User Agreement with the Transit Provider. Ordering and Delivery timelines are described in Attachment 7, Exhibit A.1., Section 2.1. |
| No. |
| 17. |
| Could you clarify the specific ADA Section 508 and WCAG 2.1 compliance requirements for the cloud-based service? |
| No. |
| No. |
| 18. |
| What are the specific reporting requirements and frequency for performance metrics and KPIs? |
| Reporting requirements are defined in Attachment 7, Exhibit A.1., Section 1.4. The Contractor will provide quarterly summary reports – which will include KPIs and accuracy metrics – within fifteen (15) days of a new calendar quarter, as described in Attachment 7, Exhibit A.1., Section 1.4.3. |
| No. |
| 19. |
| Are there any preferred or required tools and platforms for data ingestion, monitoring, and validation of the GTFS-Realtime Feeds? |
| Contractor must meet the requirements defined in the RFP. Validation must, at a minimum, be done through the Canonical GTFS-Realtime Validator, as described in Attachment 7, Exhibit A.1., Section 1.1.2. |
| No. |
| 20. |
| Can you provide more details on the project implementation plan expectations, including key milestones and deliverables? |
| As described in Attachment 7, Exhibit A, Section 4, the Transit Provider and the Contractor will collaboratively develop a project implementation plan with clearly defined steps and timelines, which will be included in the User Agreement Scope of Work. Service Acceptance is the milestone upon which the GTFS-Realtime Services meet all requirements in this SOW, as detailed in Attachment 7, Exhibit A.1., Section 1.5. |
| No. |
| 21. |
| Text: The Contractor shall provide the specification of this Ingestion Point in OpenAPI format and shall include details for protocol (e.g., HTTPS), |
Question: When the Transit Provider is changing the GTFS static data, they also need to change/provide new blocks planning accordingly. Is this how the process is intended to be implemented?
| The Transit Provider will be responsible for providing a valid GTFS schedule feed. This feed may or may not contain optional fields like block_id. |
| No. |
| 22. |
| Text: The Contractor shall provide access to Long-Term Data Storage for third-party individuals or organizations designated by the Transit Provider. |
Question: How frequently shall third-parties be able to get access? Can this be an additional paid service or can a limit be set for third-party access? (similar to restricting Passenger App requests per time period, queryable long-term data storage access should have similar restrictions for reasons of cost control)
| Long-Term Data Storage is a component of the GTFS-Realtime Services provided by the Contractor and is included in the pricing for the GTFS-Realtime Services. The Contractor is required to make data available for the previous four (4) months, as defined in Attachment 7, Exhibit A.1., Section 1.3, Item #1. Third-party individuals or organizations are only able to access Long-Term Data Storage via designation by the Transit Provider. Authorized third parties can query the long-term data storage as often as their business needs dictate. | Comment by Walters, Matt@DGS: 20240805:MW>> [Comment(s)] Cal-ITP didn’t answer the question, “How frequently shall third-parties be able to get access?” Perhaps Cal-ITP can answer this question by adding another sentence to the end of their existing response. For example, “Authorized 3rd-parties (which will include Cal-ITP) shall be able to query the long-term data storage as often as their business needs dictate.” - or something to this effect. | Comment by Walters, Matt@DGS: 20240805:MW>> [Comment(s)] Spelling error. |
| No. | | |
| 23. |
| What is the mechanism for a transit provider to initiate a claim for a service credit? |
| It is the obligation of the Contractor to report accrual of Service Credits in their quarterly reports. Contractors shall apply Service Credits for failure to meet the KPIs by crediting the invoice to the Transit Provider in the month immediately following the quarterly reporting period in which the Service Credits accrued as described in Attachment 7, Exhibit A.2, Section 1. A Transit Provider may “claim” Service Credits by disputing the Contractor’s quarterly report. |
| No. |
| 24. |
| Text: Providing a Microsoft Excel file within fifteen (15) calendar days of the Transit Provider’s fiscal year end, for the purpose of the Federal Transit Administration (FTA) National Transit Database (NTD) reporting, with the following information: |
a. Annual Vehicle Revenue Miles for each transit mode; and
b. Annual Vehicle Revenue Hours for each transit mode.
Question: As this is not directly related to GTFS RT provisioning, is this a service to be directly provided to Cal-ITP or the individual Transit Provider?
| This service will be provided to each individual Transit Provider, unless otherwise defined in the User Agreement. | Comment by Walters, Matt@DGS: 20240805:MW>> [Comment(s)] (Minor) “This service will…” |
| No. | |
| 25. |
| Text: Following Service Acceptance (Section 1.5.1), the Contractor shall provide Feed Acceptance assistance for up to three (3) Journey Planning Applications, to be selected by the Transit Provider as a component of the User Agreement. At a minimum, the Feed Acceptance assistance shall consist of the following: |
Question: Please confirm that Journey Planning Applications only can request GTFS Realtime compliant feeds and no other proprietary realtime feed formats.
| The Contractor shall only be responsible for providing GTFS-Realtime feeds. Journey Planning Applications are defined as those able to ingest GTFS-Realtime data. |
| No. |
| 26. |
| Text: ”5. The Contractor is responsible for ensuring the accuracy of association between the GTFS Schedule Feed and the GTFS-Realtime Feeds.” |
Question: Are Transit Provider’s responsibilities (like providing block plans reflecting trips in the GTFS Schedule Feed) to be exclusively defined in the individual Transit Provider User Agreements?
| Transit Provider responsibilities are defined in Attachment 7, Exhibit A.1., Section 4., which include continuously striving to provide a current GTFS Schedule Feed at a Permalink that is error free for required GTFS Schedule fields. This feed may or may not contain optional fields like block_id. |
| No. |
| 27. |
| KPI´s measuring Contractor performance (and impacting compensation levels) may depend on Transit Providers fulfilling their responsibilities. Are TP responsibilities to be exclusively defined in the individual Transit Provider User Agreements? What processes & rules will be applied to avoid Contractors’ commercial compensation being reduced due to TP’s mal-/non-performance? |
| Transit Provider responsibilities are defined in Attachment 7, Exhibit A.1., Section 4. The Contractor will not be liable for failure to meet KPIs in the case of an exclusion event, as defined in Attachment 7, Exhibit A.2, Section 5. |
| No. |
| 28. |
| Where should we identify and describe any exceptions or alternatives to Attachment 7 - Proposed Agreement exhibits A – Scope of Work, A.1 – Service Descriptions, A.2 – Key Performance Indicators and Service Credits, and A.3 – On-Vehicle Device Requirements? |
| The requirements included in Attachment 7, Exhibits A.1, A.2 and A.3 are non-negotiable. Contractors must agree to all terms if awarded an MSA under this solicitation. |
| No. |
| 29. |
| The per-vehicle unit costs to license our software is dependent on a transit provider’s fleet size. Is Cal ITP amenable to Bidders altering the Cost Workbook to reflect unit costs for the different fleet size categories we have defined? |
| Tiered pricing is not part of the Cost Workbook. The Bidder shall only enter information in cells that are highlighted in yellow. The Bidder must not reformat any part of this Workbook; any reformatting may be cause for rejection of the proposal. |
| No. |
| 30. |
| What are the primary objectives and expected outcomes of this project? |
| The objective and outcome of this MSA is a simple and high-quality GTFS-Realtime Service that is accessible for all Transit Providers. |
| No. |
| 31. |
| Do you have any preferences or restrictions regarding cloud vendors (e.g., AWS, Google Cloud, Azure)? |
| No. |
| No. |
| 32. |
| Can you provide information on the budget allocated for this project, including any constraints or flexibility in funding? |
| No. DGS is conducting this procurement for GTFS-Realtime Services on behalf of Transit Providers. Individual project size and available funding will vary from Transit Provider to Transit Provider. |
| No. |
| 33. |
| What are the key performance indicators (KPIs) and success metrics for this project? |
| KPIs are defined in Attachment 7, Exhibit A.2., Section 2. |
| No. |
| 34. |
| Are there specific data integration requirements or existing data sources that need to be incorporated into the GTFS-Realtime solution? |
| Data ingestion is defined in Attachment 7, Exhibit A.1., Section 1.2. Specific data sources will be identified by each Transit Provider and outlined in the User Agreement. |
| No. |
| 35. |
| Are there any specific compliance or regulatory requirements that we need to be aware of for this project? |
| The Contractor is responsible for adhering to all compliance and regulatory requirements that might exist for Transit Providers throughout the State of California. This MSA outlines all requirements known to affect GTFS-Realtime Services. |
| No. |
| 36. |
| What is the expected timeline for the project, including major milestones and deadlines? |
| See response to Question #20. |
| No. |
| 37. |
| Who are the key stakeholders and decision-makers involved in this project, and what are their roles? |
| DGS is conducting this procurement for GTFS-Realtime Services on behalf of Transit Providers. DGS is responsible for the content of the resulting MSA. Key stakeholders and decision makers will vary among Transit Providers. The keyholders and decision-makers within the Transit Provider will be defined within the associated User Agreement. |
| No. |
| 38. |
| What are your expectations regarding ongoing support, maintenance, and training after the implementation of the GTFS-Realtime solution? |
| Levels of Customer Support are defined in Attachment 7, Exhibit A.1., Section 3. Training is defined in Attachment 7, Exhibit A.1., Section 3.1. Response times for all customer support platforms are defined in Attachment 7, Exhibit A.1, Section 3.2. |
| No. |
| 39. |
| Can you provide details on your existing IT infrastructure and any potential integration points with the new GTFS-Realtime solution? |
| No. DGS is conducting this procurement for GTFS-Realtime Services on behalf of Transit Providers. Existing IT infrastructure and any potential integration points will vary among Transit Providers. |
| No. |
| 40. |
| What are your expectations for user training and onboarding for the new system? |
| Training is defined in Attachment 7, Exhibit A.1., Section 3.1. Training is a component of the onboarding activities necessary to achieve Service Acceptance, as described in Attachment 7, Exhibit A.1., Section 1.5.1. |
| No. |
| 41. | |
| Are there any known risks or challenges that we should be aware of and address in our proposal? | |
| DGS is conducting this procurement for GTFS-Realtime Services on behalf of Transit Providers. Risks and challenges will vary among Transit Providers. | Comment by Walters, Matt@DGS: 20240805:MW>> [Comment(s)] (Minor) Similar feedback as for Items #37 and #39 - Cal-ITP might want to spell “This” out (e.g. “Risks and challenges …”). |
| No. | |