POTOMAC AND RAPPAHANNOCK TRANSPORTATION COMMISSION (PRTC) AMENDMENT TO SOLICITATION REQUEST FOR PROPOSALS (RFP #18-03) ADDENDUM No.

Transcription

1 POTOMAC AND RAPPAHANNOCK TRANSPORTATION COMMISSION (PRTC) AMENDMENT TO SOLICITATION REQUEST FOR PROPOSALS (RFP #18-03) ADDENDUM No. 1 Issued: December 11, 2017 RFP No. #18-03 Title: Real Time Passenger Information App Contact: Perrin Palistrant ppalistrant@omniride.com Telephone: DESCRIPTION OF AMENDMENT above numbered solicitation is amended as follows: 1. ANSWERS TO SUBMITTED QUESTIONS Providing a matrix of all submitted questions attached herewith, Real Time Passenger Information App Questions. 2. PROPOSAL COVER PAGE AND CLAUSE I.10 TIMELINE procurement timeline has been revised. Proposals are now due December 22, at 12:00 noon. DELETE: REPLACE WITH: Cover Page Cover Page (Revised) attached herewith DELETE: Page 5 REPLACE WITH: Page 5 (Revised) attached herewith 3. RFP SUMBISSION Proposals should be submitted to Betsy Massie instead of Cynthia Porter-Johnson, revised clause IV.3 RFP Submission. DELETE: Page 17

2 REPLACE WITH: Page 17 (Revised) attached herewith 4. PREPROPOSAL MEETING ATTENDEES SIGN-IN SHEET Attached herewith 5. OWNERSHIP OF DATA PRTC is seeking further legal clarification and will provide additional contract language and clarification in a further addendum. Offerors must acknowledge receipt of this amendment by returning signed original with the Proposal package prior to the hour and date specified in the solicitation. Company Address City State Zip Code Name of Person Authorized to Sign Print Signature Date

3 PRTC Real Time Passenger App REQUEST FOR PROPOSAL: #18-03 Response to Prospective Bidders Questions and Requests for Clarifications December 8, 2017 Section(s)/Page(s) Question/Clarification Date Submitted/ Response Prospective Bidder Passenger App, A. Components, C. System Management / 12, 13 vendor shall create an algorithm to predict real-time vehicle arrivals using PRTC s GTFS-RT feed. But later is says System shall provide a real-time management interface to allow assignment of buses to routes by dispatchers. 11/3/17 - Transee One of the issues that PRTC faces with the realtime feed stems from MDT errors on the bus. If a bus operator does not or is not able to log into the MDT, no real-time data is pushed out to the feed. We require a real-time management interface that allows dispatchers to assign buses to routes allowing the real-time app to recognize bus positions of assigned buses to routes and report real time arrivals. This interface would be complimentary to the feed. System shall allow administrator systemwide and route specific alerts to be posted immediately or in advance for posting at pre-defined times. Both of these features are handled by GTFS-RT. Vehicle Positions and Trip Updates include the route and trip for each bus and there is a file dedicated to alerts. I'm not sure why these are requirements unless the GTFS-RT data is going to be removed. PRTC currently has software that allows us to push out route specific alerts through the realtime feed. However, the current software is tedious and time-consuming. PRTC will continue to push out certain alerts through software already installed via the real-time feed, but PRTC additionally requires software through the app that allows an administrator to manage alerts pushed out through the app to mobile/smartphones.

4 111.1 Real Time Passenger App / 12 selected vendor shall implement a system that is based on proven solutions that use current technologies. vendor shall provide all required hardware, software (most current version available), training, documentation, warranty and maintenance necessary to meet the requirement of this RFP. To the extent practicable, the selected vendor shall use existing hardware on the vehicles. (See Exhibit 1 for existing vehicle hardware). 12/1/17 - Ridesystems Zonar Equipment on PRTC buses: Zonar V3: maticsdevices/?gclid=cjwkcaiax57rbrbkeiwa8yzdue xtpsqxp0eul_- FJrkIZ2yKhFOXHNafyp_kblRjCuDUOf3ajva0YBo CdZMQAvD_BwE a. Can you please provide specific hardware types and model numbers for all Zonar and Trapeze hardware? We are interested in utilizing existing hardware if possible to save PRTC on cost. Zonar 2010A: 0-electronic-verified-inspection-report/ Zonar Product Inquiries: (877) Trapeze Equipment on PRTC buses: n_sheets/trapeze_solutionsheet-its- MDTTouch_FIN_web_ pdf

5 eets/ivlu_version_01.pdf Modems on Buses: 18 buses in the fleet have the Sierra RV50: dium=cpc&utm_campaign=ns&lsc=2017_q4_p da_google_cpc_web_ns&cid=atha- 47B6ZX&gclid=CjwKCAiA6qPRBRAkEiwAGw4Sd vufwz2oagt74ivaks5xpzg7gwtezalixur6vxhhqdubgpwvnabsh occlaqavd_bwe Real Time Passenger App, A. System shall have a refresh frequency of no more than three seconds. 12/1/17 - Ridesystems Rest of the bus fleet has the Sierra Wireless Airlink LS300: Zonar reports in real time all bus activities. However, they updates are sent to

6 Components / 12 Often, the update rates of the GPS tracking hardware of companies such as Zonar and Trapeze is slower than what is ideal for providing real time tracking for passengers. Can you confirm that these companies are willing to increase their update rates if necessary to real time or near real time rates? the Zonar servers (browser interface) every 18 seconds. Trapeze: Confirmed. Mobile and Smartphone / 13 In regards to the User/Passenger data being collected from the ios/android device such as GeoLocation, TripPlanning Requests, survey Answers etc., does that data exclusively belong to the Agency, Vendor or is it co-owned? Any restrictions to the Post-Usage of the data by the vendor in the event the Vendor has the right to use or resell the data? 11/17/17 - Tangente data exclusively belongs to PRTC. vendor has no rights to use or resell the data without prior consent from PRTC. Passenger App A. Components / 12 Source Code of the Application. Do you require a copy of the Source Code in the event you have a fall out with the Vendor? 11/17/17 Tangente PRTC does not require a copy of the source code. Passenger App D. Reporting / 14 Integration of Google Analytics in the Application and Ownerships of those Statistics and Data. Would you require Analytics to be gathered inside the Application as it s accustom today in Websites to help PRTC optimize and better understand Passenger patterns? 11/17/17 Tangente Please refer to RFP section Passenger App, Section D. Reporting / 14 Mobile and Smartphone / 13 Profile creation. 1) Should the Passenger/User absolutely require to create a profile ( /Password) to use the application? Most transit applications do not require this? 2) For more advanced features or future features such as Off Route Paratransit Request and Fare Collection this is a must, in my opinion? 11/17/17 Tangente 1. app may require passenger/user to create an account to retain history of routes that are of interest to them. However, passenger/user should not absolutely be required to create an account to use the application. Please refer to section Passenger App, Section B. Mobile and Smartphone - If system allows end-users to create accounts, end-users shall have the ability to delete the account without administrator assistance. 2. Off-Route Paratransit Request and Fare Collection are not required for this RFP.

7 Passenger App / 12 Neighboring Transit Partners or Agency GTFS Integration. 11/17/17 Tangente Trip planning functionality is not a requirement of this RFP. Ability to have a Trip Planning algorithm to accommodate schedule a trip that uses multiple services including other GTFS (Fairfax, Alexandria, Metro, Arlington, also RVA Bike Share ) into the proposed route, would this be of interest? Passenger App / 12 Re: "PRTC is also considering development of several other mobile applications including mobile ticketing and mobility on demand solutions. se efforts are still in the conceptual design phase and not included in this Scope of Work. It is highly likely that PRTC will implement one or more of these initiatives and may desire some level of integration with the Real Time Passenger Information App in the future. (p. 12). If mobile ticketing and on-demand capability are supported in the app software proposed, would it be considered as a benefit to the final scoring of a proposal? If mobile ticketing and on-demand capability are supported in the app software proposed, PRTC will not consider it as a benefit to the final scoring of a proposal. Mobile and Smartphone / 13 Would PRTC agree to part of the app being branded (certain customized sections and route colors) rather than the entire app, especially if it entailed lower costs? Has PRTC considered a universal app (supported in other cities and with other mobility options), which would also provide its customers complete transit information for the Washington Metropolitan Area? PRTC would agree to part of the app being branded, rather than the entire app. Please refer to section Passenger App, page 13, and section B. Public Website. Vendor shall design a website banner that prominently uses the customer-supplied logos/graphics to clearly identify customer s transit system and a web address this is easy to market.

8 Passenger App A. Components / 13 Re: "System shall push out RTPI system alerts and alerts sent by PRTC administrator(s). on page 13. Does this refer to the alerts.prtcrtf.com/alerts.pb link? format of these alerts allow them to be used in real-time (as soon as they are issued). On page 14, it is stated that "System shall allow administrator systemwide and route specific alerts to be posted immediately or in advance for posting at pre-defined times. and "System shall allow administrator alerts to be removed manually and automatically at a pre-defined time in the future." As PRTC is the administrator of the alerts through the alerts.prtcrtf.com/alerts.pb link, PRTC is the determiner of the content and the time that alerts are posted in the realtime information. Could PRTC clarify if this is not the case? Please refer to response to Transee 11/17.17 Passenger App, A. Components, C. System Management / 12, 13 Passenger App A. Components / 13 Re: "System should provide an option to use a LCD screen for display inside the agency facility as well as remote location(s). on page 13. Could PRTC describe what it would like as content to be displayed on the screen? PRTC currently has LCD screens on display inside the agency facility and future plans for remote locations near bus stops. LCD shall display routes, differentiated by design and/or color and the route arrival times to the closest bus stop. Mobile and Smartphone / 13 Are arrival estimates via SMS text messaging essential to the project? Would PRTC allow for notifications to be pushed out from the app instead? If not, would PRTC consider procuring this service separately? PRTC requires a system that provides arrival estimates via SMS text messaging. This requirement is for passengers/users who do not have access to a smartphone. PRTC would not consider procuring this service separately. Public Website / 13 Are (1) arrival estimates and (2) a website banner with logos/graphics an essential component to the website feature of this project? Please refer to section Passenger App B. Public Website. Passenger App A. Components / 13 Re: "System should provide optional capability and integration of Real-Time Transit Data API, including developer documentation that allows for querying data from AVL services. Contractor should state what format(s) the output PRTC is not looking to integrate an API instead of the GTFS-RT feed in the future. PRTC requires querying historical data from AVL services.

9 data is available. (page 13). Could PRTC please provide more specific information on this point? Is PRTC looking for the app to be able to integrate an API instead of GTFS-realtime in the future? Or does this rather refer to PRTC wanting to retrieve past AVL information? Passenger App A. Components / 12 Re: vendor shall create an algorithm to predict real-time vehicle arrivals using PRTC s GTFS-RT feed. (page 12). Real-time arrival predictions are already part of PRTC s realtime feeds. Is PRTC looking to replace these predictions with new predictions? PRTC s real-time feeds only provide service alerts, trip updates and vehicle positions. vendor shall create an algorithm using the realtime feeds and the static feed to provide real time arrivals. Passenger App C. System Management / 13 Re: "System shall provide a real-time management interface to allow assignment of buses to routes by dispatchers. and "Certain management functions (e.g., assigning buses, activating routes) shall be allowed from internetenabled smartphones and tablets. (page 13). Usually the procurement of a CAD/AVL system includes this component. Does PRTC currently have this component but is looking to replace it? Is this component essential to the project? Please refer to response to Transee 11/17.17 Passenger App, A. Components, C. System Management / 12, 13 Passenger App D. Reporting / 14 Re: "Offeror shall present standard performance reports. (page 13) What metrics does PRTC consider standard. Could PRTC please provide more information on what it is looking for in a performance report? Could PRTC specify if the performance reports have to do with the performance of the app (e.g. number of downloads or users) versus the performance of the AVL system (e.g. real-time accuracy?) PRTC requires the vendor to present their current standard performance reports in regard to both app performance and AVL system. PRTC would also be interested to know if any of the vendor s standard reports are customizable. Public Website / 13 Page Sect B Public Website states: 11/16/17 - WAAV 1. Please see response for Tagente III.1 Real Time Mobile and Smartphone / 13

10 "Users shall have the ability to view only routes that are of interest to them. System to remember users chosen routes from the last time they loaded the website." 1. Does this indicate that each user downloading the app registers an account? In that account, is history or routes viewed, favorite routes, or current location play any part of what the UX presents when the rider first looks at their phone? 2. How does the application expect to identify users? by login, password?, log in only? or other. 3. Does this database record MAC address for smart-device? What happens when rider shows up after Christmas with a new phone? 4. Is any or all of this information considered PID (Personally Identifable Data)? If so, what are the security requirements connected to storage, update, backup and usage of this data? 5. Who owns the data of the riders? 2. Application would identify users by login and password. 3. Not a requirement to record MAC address for smart-device. User information should be store in a profile within an account they create within the app. 4. Please refer to GSA s Rules and Policies Protecting PII Privacy Act 5. See response provided for Tangente 11/17/17 for Passenger App B. Mobile and Smartphone / 13