Problem:
The current Waze system for classifying "Roadworks" events relies on a rigid and overly limited software logic that fails to match the real-world dynamics of construction zones. Currently, the application offers only three static options, which are highly inadequate. Roadworks are frequently located outside the active driving lanes—such as maintenance on the shoulder, grass cutting, guardrail repairs, or ditch cleaning—where no lanes are closed and traffic flows freely, yet the road hazard remains active. The lack of a specific option for "general roadworks without lane blockage" confuses drivers.
This issue becomes critical once an initial alert is detailed by a user as a "Lane Closure." At this point, the interface locks into a software trap, presenting subsequent drivers with a binary "Yes/No" question (Is it still there?). Because construction sites are highly dynamic—workers constantly move machinery to the opposite lane or reopen the road entirely overnight while leaving the asphalt scraped—users have no way to correct the status. This lack of flexibility forces drivers to mass-vote using the incorrect "Not there anymore" option simply to remove the non-existent lane closure, which automatically deletes the entire alert and leaves the hazardous zone completely undocumented on the map.
Solution:
Introduction of two dynamic, 5-option menus that enable detailed classification and real-time state changes based on majority voting, paired with an automated alert recovery algorithm and extended time-to-live thresholds.
Section 1: Interface Options for the Initial "General Roadworks" Alert
When a driver approaches a standard roadworks alert, the interface must provide the following 5 options:
1 Left lane closed
Effect: Modifies the alert state and displays a visual indicator for a closed left lane.
2 Right lane closed
Effect: Modifies the alert state and displays a visual indicator for a closed right lane.
3 No lane closures / Clear passage
Effect: Retains the baseline roadworks alert and refreshes its expiration timer. This option is critical for flagging shoulder work or active construction zones during off-peak periods (e.g., night shifts) when heavy machinery is cleared but hazards like scraped asphalt remain.
4 Full road closure
Effect: Upon receiving 3 consecutive votes within a 5-minute window, the routing algorithm automatically applies a full closure to the road segment (red-and-white line).
5 Not there anymore
Effect: Completely purges the alert from the map if all construction activities have concluded.
Section 2: Interface Options for an Already Active "Lane Closure" Alert
When a driver approaches a hazard already marked on the map as a lane closure, the interface must not display a simple binary prompt. It must enable corrective input via the following 5 options:
1 Still closed
Effect: Confirms the current state and extends the active duration of the alert.
2 Switch closed lane
Effect: Automatically swaps the visual indicator from left to right lane (or vice versa), reflecting that the crew and equipment have shifted positioning.
3 Lanes reopened / Keep roadworks alert
Effect: Removes the specific lane blockage indicator but reverts the object to its baseline state as a general roadworks alert (all lanes passable, but construction zone remains active).
4 Full road closure
Effect: Instantly escalates the alert to a full road segment closure.
5 Not there anymore
Effect: Completely purges the alert from the map upon verified completion of all works.
Section 3: Logic for Reverting from a "Full Road Closure" Back to a "General Roadworks" Alert
Once a segment is fully closed to navigation (Full road closure), the system must utilize an intelligent mechanism for reopening and reverting to baseline mode to prevent segments from remaining permanently blocked.
Data Collection Mechanism: Because navigation reroutes the general traffic flow, Waze must track the passive GPS traces of drivers who bypass the closure anyway (e.g., local residents or the first vehicles clearing the area upon reopening).
Trigger Condition: When the system detects a user's GPS trace moving through the closed segment at a speed greater than pedestrian pace (above 15 km/h), the app will automatically prompt them with an overlay banner: “Is the road reopened?”
State Reversion Rules:
1 Selecting “Reopened, but roadworks active” \rightarrow Instantly removes the red-and-white closure line, reopens the segment for routing, and restores the baseline "Roadworks" alert.
2 Selecting “Reopened, roadworks finished” \rightarrow Reopens the segment for routing and completely deletes the alert from the map database.
Section 4: Radical Increase of Time-To-Live (TTL) and Removal of the 30-Minute Expiration Limit
The current software architecture automatically drops roadworks or lane closure alerts after a brief 30–35 minute window if continuous active confirmations are missing. This is a critical software defect during nighttime hours or on low-traffic routes where a segment might see no user activity for over half an hour, causing valid alerts to vanish and leaving the road hazardous.
New Software TTL Framework:
1 12-Hour Minimum Longevity: Every submitted baseline roadworks alert (or escalated lane closure) must automatically receive a fixed Time-To-Live (TTL) metadata value of at least 12 hours within the database.
2 Reset upon Transformation: Any manual state correction performed by a user (such as shifting from general roadworks to a lane closure, or swapping lanes) resets this 12-hour countdown back to zero.
3 Protection Against Premature Automatic Deletion: The alert can be removed before the 12-hour expiration mark only and exclusively through an accumulation of negative crowd-sourced votes ("Not there anymore"), never via a temporary absence of traffic data.