SAFETY REQUIREMENTS

When using Google Maps Platform services within Customer Applications intended for real-time driving, Customer will adhere to the following requirements:

1.1. Information Presentation for Glanceability and Focus. When the vehicle is in motion, information must be designed for quick recognition and minimize glance time away from the road. The Customer Application must avoid displaying extraneous information that could dangerously draw the driver's attention away from the driving task.

1.2. Input Restrictions While Driving. Complex interactions requiring significant visual-manual attention (e.g., detailed route modification, extensive Point of Interest browsing, text entry beyond simple search queries) must be locked out or significantly simplified when the vehicle is in motion, consistent with established automotive safety guidelines such as the principles outlined in the NHTSA Visual-Manual Driver Distraction Guidelines for In-Vehicle Electronic Devices or equivalent regional standards such as Euro NCAP. Voice input should be prioritized for necessary in-motion tasks.

When using Google Maps Platform services to create real-time navigation functionality, Customer will adhere to the following requirements:

2.1. Location Accuracy. The Customer Application must monitor GPS signal quality and accuracy. If location accuracy degrades significantly (e.g., during signal loss in tunnels, urban canyons), the Customer Application must provide a clear visual indicator to the user that the displayed location may be inaccurate and potentially cease providing precise maneuver guidance until accuracy is restored. Customer will not represent an uncertain location as precise.

2.2. Real-Time Data Latency/Staleness. When displaying real-time data (e.g., traffic conditions, speed limits, incident reports) obtained from Google Maps Platform services, the Customer Application must account for potential latency. Customer will not represent potentially stale or unavailable data as real-time data, preventing users from relying on outdated critical information.

2.3. General Route Visibility. The active navigation route must be clearly and unambiguously visually distinguished from the underlying map infrastructure and any alternative routes shown (e.g., via distinct color, line weight).

Customers who are using Google Maps Platform services in conjunction with third-party services or products to create real-time navigation functionality or driving applications will adhere to the following requirements:

3.1. Third-Party Route on Google Map

(a) Route Snapping and Continuous Matching: Customers using a third-party routing engine (i.e. non-Google routing) to generate routes displayed on a Google Map base layer (provided via the applicable Services) must implement and maintain processes to: (i) accurately snap or geometrically align the third-party route to the road network shown on the Google Map before initiating an active navigation session, and (ii) continuously monitor and validate during the session that the displayed route remains consistent with the Google Map geometry and constraints (as detailed in 3.1(b)). Significant deviations must trigger corrective actions (e.g., route re-validation, user notification, etc.).

(b) Constraint Validation: This validation must ensure the third-party route adheres to features visible on the Google Map, including the physical road network geometry. The maximum permissible deviation between the third-party-provided polyline and the centerline of the corresponding road segment on the Google Map display must not exceed 10 meters at any point along the active route. Processes must be in place to detect and handle deviations exceeding this threshold.

(c) Guidance Consistency: The Customer Application must not present guidance (visual or audible) based on the third-party route that directs the user to perform maneuvers contradicting the constraints shown on the Google Map (e.g., directing a left turn where the Google Map shows a "No Left Turn" sign or restriction, routing the wrong way down a visible one-way street).

(d) Display Data Refresh: Mechanisms must ensure that both the third-party route polyline display and the underlying Google Maps Content are refreshed at sufficient frequency to minimize visual staleness and maintain visual alignment accuracy consistent with the defined accuracy threshold (Section 3.1(b)), especially considering vehicle speed and road network density. To ensure the underlying third-party-provided route instructions remain current based on real-time conditions known to such third party (e.g., traffic, closures reflected in API responses), the application must request an updated route calculation from the relevant third party service at a minimum frequency of every 15 seconds during active navigation, or based on triggers indicating potential route deviation or changing conditions reflected in data feeds accessible to the developer.

3.2. Google Route on Third-Party Map

(a) Polyline-to-Map Alignment: Customers displaying Google-provided route polylines on a third-party map (i.e. non-Google map) must implement and maintain rigorous processes to continuously verify that the displayed polyline accurately aligns with the visible road geometry on the third-party map.

(i) Accuracy Threshold: The maximum permissible deviation between the Google-provided polyline and the centerline of the corresponding road segment on the third-party map display must not exceed 10 meters at any point along the active route. Processes must be in place to detect and handle deviations exceeding this threshold.

(ii) Display Data Refresh: Mechanisms must ensure that both the route polyline display and the underlying third-party map tiles are refreshed at sufficient frequency to minimize visual staleness and maintain visual alignment accuracy consistent with the defined accuracy threshold (Section 3.2(a)(i)), especially considering vehicle speed and road network density. To ensure the underlying Google-provided route instructions remain current based on real-time conditions known to Google (e.g., traffic, closures reflected in API responses), the application must request an updated route calculation from the relevant Service (e.g., Directions API, Routes API) at a minimum frequency of every 15 seconds during active navigation, or based on triggers indicating potential route deviation or changing conditions reflected in the Services accessible to the developer. 

(b) Instruction Applicability Validation: Developers displaying Google-provided navigation instructions (textual or audible) in conjunction with a third-party map must implement processes to validate that the instructions are contextually valid and correspond accurately to the features present on the displayed third-party map. Instructions referencing features not present or incorrectly represented on the third-party map must be suppressed or adapted appropriately to avoid user confusion.