2025-POL-002 Addendum 3.pdf

Addendum 3 Bid 2025-POL-002

Digital Parking Software and LPR System

In red you will find our response to questions received:

1.

2.

3. Regarding the requirement to furnish and install

4. all necessary hardware and software for one mobile LPR System on the 2025 Ford

Maverick, we want to confirm if you require a strictly vehicle-mounted solution or if you’re open to a dual approach. Our system supports both a vehicle-mounted and a handheld device

5. option which can offer enhanced flexibility for scenarios like curbside and parallel parking enforcement. Could you please clarify your preference so we can tailor our proposal accordingly?

6. The City is seeking a vehicle-mounted system. However, proposers my offer optional enhancements.

7.

8.

9. In Section 4.A(2), can you confirm the complete

10. data schema for migrating existing resident plate records such as requiring normalized license plate numbers (standard alphanumeric format), unique resident IDs, issue and expiration dates, permit type, and status codes and specify if additional metadata (e.g.,

11. geolocation coordinates, timestamp of issuance) is needed?

12. 4.A.2 - The City currently has an existing database of residents’ license plates that needs to be migrated to the proser’s digital permit system.

13.

14.

15. For the web-based permit system in Section 4.A.1,

16. do you require a two-step authentication process that initially verifies a user via license plate recognition followed by a secondary credential such as a driver's license number or a mobile OTP with defined encryption standards (e.g., TLS 1.3, AES-256) and

17. session management policies?

18. Dual-factor authentication is not required.

19.

20.

21.

22. Regarding integration with existing city databases

23. (Section 4.A.2), does the City mandate connectivity to a specific platform (such as

Microsoft SQL Server, Oracle, or PostgreSQL), and will the City provide a documented API with secure connection strings or standardized connectors (e.g., ODBC/JDBC) to enable

24. real-time data synchronization? Yes. Ideally we would like to be able to connect with SQL or PSQL using ODBC.

25.

26.

27.

28. For supporting multiple permit types in Section

29. 4.A.3, can you confirm if each category such as Resident Parking, Guest Parking, and

Specialty permits (e.g., Fishing, Loading Zone, Special Events) requires adherence to distinct business logic rules? For instance, should Resident Parking enforce fixed validity

30. dates (e.g., May 1 to October 1), while Guest Parking utilizes dynamic, tiered fee models with proration based on usage duration, and Specialty permits incorporate eligibility validations based on vehicle type or residency status? Is a configurable rules engine

31. expected to manage these parameters, or are pre-established rule sets provided for direct implementation?

32. Resident, Easton’s Beach, King Park (auto & boat) are fixed validity. Guest Passes are flexible for specific dates.

33.

34.

35. In Section 4.A.6, can you confirm if the reporting

36. requirements include granular metrics such as permit issuance volumes segmented by permit type, revenue breakdowns (including fee and penalty collections), and enforcement statistics (e.g., violation counts by time and location)? Should these reports be available

37. via real-time, interactive dashboards with drill-down capabilities, or is scheduled batch export (e.g., CSV/PDF) acceptable, and are there any specific KPIs or compliance report templates that must be supported?

38. Proposal should list the reports the proposed system can provide, including back-office report types and availability.

39.

40.

41. In Section 4.B.3, for integration with the Passport

42. Mobile Payment App, do you require adherence to specific API standards such as a defined JSON schema with explicit field definitions, OAuth 2.0 token-based authentication, and TLS 1.2/1.3 secure endpoints for retrieving active parking session data? Are there

43. established performance parameters, rate limits, or error-handling protocols that our integration must support? We need the solution to be able to check against the passport database to see if parking has been paid for and other active session data so violations can be flagged and enforced. It doesn’t need to integrate with the mobile payment app directly. Passport has existing API’s using Access Tokens. More information is available here: https://developer.passportinc.com/docs/integration-solutions/f17572d5e0dff-full-parking-payments

44.

45.

46.

47. In Section 4.B.7, for analytical capabilities, do

48. you require the system to capture and report granular metrics such as average parking duration segmented by permit type and time interval, peak violation times detailed by hour and zone, and geospatial violation density? Should the analytics include correlations

49. between payment compliance and enforcement outcomes, and are interactive dashboards with GIS mapping or scheduled batch reports (CSV/PDF) mandated?

50. The primary purpose of the LPR System is enforcement of parking regulations. Proposal should detail what data, if any, is available from the proposed System.

51.

52.

53. In Section 4.B.1, regarding the installation on

54. the 2025 Ford Maverick, can you confirm if the City specifies optimal mounting positions

(e.g., roof, hood, or fender locations) for the LPR hardware, and if there are explicit power supply constraints such as a 12V DC input with defined tolerance levels or

55. recommended interfacing standards—that must be adhered to?

56. Mounting position will be based on the proposers recommendation for optimal performance reading the license plates of both parallel and diagonally parked vehicles. The vehicle is equipped with a 12V battery.

57.

58.

59. In Section 4.B.2, for network disruptions, do you

60. require the mobile LPR system to implement an offline mode that securely caches recognition events for up to 30 minutes with delta synchronization and conflict resolution upon reconnection? Should this leverage an encrypted local store (such as SQLite), and

61. are there specific data integrity protocols or throughput benchmarks (e.g., hash verification, idempotency keys) that must be met?

62. Yes, off-line operation is required. Any simple local DB like sqllite is fine. Given that we are only transmitting LPR data, there is no specific protocol or benchmark that must be met.

63.

64.

65. For the mobile enforcement app in Section 4.B.6,

66. is integration required with external law enforcement or municipal ticketing systems to cross-reference issued citations with local databases? If so, do you mandate using a standardized RESTful API with secure OAuth2 authentication, and can you specify the

67. required data fields (e.g., citation ID, license plate, violation code, timestamp, officer ID) along with synchronization intervals and conflict resolution protocols for real-time data consistency?

68. Integration with the city’s existing ticket management system (Passport) is required.

69.

70.

71. In Section 4.A.3, does the digital permit system

72. need to support dynamic pricing models such as time-of-day rate adjustments, occupancy-based surcharges, or tiered discounts for multi-permit applications and should these pricing configurations be managed through a configurable rules engine in the administrative

73. interface that allows for granular controls (e.g., setting discount thresholds, promotional periods, and pricing tiers)?

74. Yes. There may be different pricing fees for multiple applications, or other factors 75.

76.

77. Do you want to implement granular role-based access

78. controls defining specific permissions for user groups like Parking Enforcement, Finance, and IT? If so, Could you detail the exact data views required for each role such as real-time violation statistics and permit alerts for Enforcement, detailed revenue

79. breakdowns and transaction logs for Finance, and system performance and audit logs for IT and specify if integration with existing ERP or financial systems is mandated?

80. Yes. Exact data views for each role to be determined upon review of the data available in the proposal, e.g. a check box system controlled by an administrator.

81.

82.

83. In Section 4.B.6, does the mobile LPR system require

84. an integrated false positive mitigation mechanism that includes a manual override and real-time feedback loop for immediate correction of misread license plates? Should the system log override events to facilitate continuous machine learning improvements,

85. and are there defined error thresholds to trigger such interventions?

86. Yes, there should be an option to manually override a misread. Yes syslog can override, and no error thresholds, all overrides and corrections should be done manually.

87.

88.

89. In Section 4.B.2, can you specify the quantifiable

90. performance benchmarks for the mobile LPR system in high-density scenarios? For example, should the system achieve a minimum of 95% recognition accuracy under conditions of overlapping vehicles and occlusions, and must citation issuance occur within 1 second

91. of detection? Are there defined environmental or operational parameters such as low-light performance, rain conditions, or vehicle speed thresholds that we need to factor into our load testing and system validation?

92. Proposal should include system’s LPR accuracy rate. Citations should be issued in real time. The system will need to operate in low light (nighttime) and inclement weather between May 1 and October 31. The system will be enforcing parking regulations, not moving violations.

93.

94.

95. In Section 4.A.3, for multi-tiered permit validations,

96. do you require the digital permit system to implement advanced state management and transactional consistency (e.g., via ACID transactions or event sourcing) for initial issuance, renewals, and status updates after resident data changes? For instance, should

97. the system trigger an automatic revalidation upon detecting changes in resident status and maintain a detailed audit trail including user IDs, timestamps, and change reasons to ensure data integrity and compliance with audit standards?

Ideally yes. This all depends on the functionality and design of the overall system. i.e.

END OF ADDENDUM 3