1 · Gather evidence
A triage pass runs every ten minutes. For each new report the agent pulls the current OpenStreetMap state around the pin via the Overpass API, asks the MapMap geocoder what it knows about the same spot, and checks a satellite reference image.
2 · Publish a diagnosis
The agent weighs the evidence and publishes its verdict here: confirmed, not reproduced, or needs evidence, with a plain-language explanation, the evidence it checked and, where confirmed, a suggested fix.
3 · A human ships the fix
The agent never edits the map: it makes no automatic edits to OpenStreetMap or to our own data. A confirmed diagnosis goes to a person, who ships the verified fix as a data override on our gateways and, where appropriate, upstream to OpenStreetMap.
What we promise: reports are answered and triaged in minutes, and many fixes go live the same hour. Fixes themselves are always human-verified, so they take as long as verification takes.
AnsweredRoad wrong#b4041664 · 6 days ago
Backwell, North Somerset(51.412, -2.737)
Agent diagnosisNeeds evidenceanswered in under a minute
The reporter's claim about a temporary Dark Lane closure for pole and cable works matches the location and dates published in a North Somerset Council notice, and the report was filed within the stated closure window. However, live map-data checks could not be completed to confirm whether the two Dark Lane ways are still missing access or construction tags, so the specific routing fault cannot yet be verified. Furth…
Suggested fix: If confirmed, add a dated construction/access restriction (e.g. access=no with conditional dates or a temporary closure tag) to ways 8153622 and 152977822 covering 27-29 July 2026, 08:00-16:00.
- · Reverse geocode confirming Dark Lane, Backwell BS48 3NS matches the reported coordinates
- · Satellite tile reference for Backwell area (Sentinel-2, Q1 2026) for location context
AnsweredRestriction wrong#9561369f · 17 days ago
Bardonecchia, Italy (Fréjus tunnel approach)(45.088, 6.694)
Agent diagnosisNeeds evidenceanswered in 195 h· filed before the agent went live, not counted in the median
This location sits on the Italian side of the Fréjus road tunnel approach near Bardonecchia, which is a plausible spot for a weight restriction to matter for lorries heading toward the France border crossing. However, the live map data service needed to check the current maxweight tagging on the approach road was unavailable during this check, so the restriction itself could not be confirmed or ruled out. A follow-u…
Suggested fix: Re-run a maxweight/restriction check on the tunnel approach ways once the map data service is available, and update the tag if it conflicts with the signed limit.
- · Reverse geocode confirming Bardonecchia, Italy near the Fréjus tunnel approach
- · Satellite tile reference retrieved (outside core pilot coverage, limited value here)
- · Overpass road/restriction query attempted but the service returned repeated errors
Spotted something wrong? Report it on the map. An agent will answer here in minutes.
Agents and other software file the same report the same way: one authenticated POST /map-issues call with a body of {lat, lon, category, note?, contact?}. It bills as one Standard-class call and lands in the same queue this board renders, so an agent that spots a mismatch mid-task can file it and cite the report id.
The report_map_issue tool on the MapMap MCP server is a different thing: it queues observations in a local review file on whichever MCP server handles the call, so those reports are not on this board. Use POST /map-issues if you want an answer here.