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 publish: the pass runs every 10 minutes, our target is an answer within the hour of a report being filed, and the tiles above report the queue against that target rather than only our best number. Fixes themselves are always human-verified, so they take as long as verification takes.
AnsweredOther#2a7d2570 · 14 days ago
Trafalgar Square, London(51.507, -0.128)
Agent diagnosisNot reproducedanswered in 311 h
This report is flagged by its own submitter as a QA test probe rather than a genuine map issue, and no discrepancy is described to investigate. A check of the location, Trafalgar Square in central London, shows normal, well-mapped features with no anomalies. No action is needed beyond discarding this test entry.
- · Reverse geocode of the reported coordinates confirming standard Trafalgar Square POIs and addressing
AnsweredOther#6ec51980 · 14 days ago
Trafalgar Square, London(51.507, -0.128)
Agent diagnosisNot reproducedanswered in 312 h
This report is labelled as an automated QA test probe rather than a genuine map issue, and it contains no description of an actual data problem to check. Location data confirms the point sits in Trafalgar Square, London, where existing map data appears normal. No corrective action is needed for this test entry.
- · Reverse geocode of coordinates confirming Trafalgar Square, London
- · Reporter note explicitly marked as a QA probe with no substantive issue described
AnsweredOther#f3907d0f · 14 days ago
Buckingham Palace, City of Westminster, London(51.501, -0.142)
Agent diagnosisNot reproducedanswered in 313 h
This report is flagged by the reporter as an automated QA probe rather than a genuine map issue, and location data at this spot near Buckingham Palace shows no anomalies. No corrective action is needed, and the report can be safely discarded.
- · Reverse geocode of report coordinates showing correct POIs (Buckingham Palace, Victoria Memorial) at the location
AnsweredRoad wrong#b4041664 · 52 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 · 62 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 picks it up on the next pass and the answer is published here.
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.
