Skip to content

A triage pass runs every 10 minutes, and the answer is published here.

When a map issue is reported, by a person using the report button on the map or by software calling POST /map-issues with an API key, an agent investigates it against OpenStreetMap ground truth, our own geocoder and satellite imagery, and publishes its diagnosis here. The triage pass runs every 10 minutes and our target is an answer published within the hour of a report being filed. It is a target, not a promise, so the numbers below say how we are doing against it, including when we are behind. Verified fixes always ship through a human: the agent diagnoses, it never edits the map.

Median time to first answer
155.4 h
Across 6 reports filed since the agent went live on 26 July 2026
Awaiting an agent
0
Nothing waiting. 7 of 7 reports answered
Fixes live
0

How triage works

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.

Diagram of a four-stage loop: a pin dropped on a road network, a scanning node, a slab of verdict lines, a corrected road network, and a return arc closing back to the startDiagram of a four-stage loop: a pin dropped on a road network, a scanning node, a slab of verdict lines, a corrected road network, and a return arc closing back to the start
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.

Recent reports

AnsweredRoad missing#b2240ba7 · 24 days ago
Googleplex, Mountain View, California(37.422, -122.084)
Agent diagnosisNeeds evidenceanswered in 5 min

We could not confirm which road the report refers to, and our live road-network check failed to return results for this location. The surrounding area already has detailed building, address and point-of-interest data, which suggests the map here is not completely empty, but a direct road-layer check could not be completed this time. Further investigation with specific road or street information would help confirm th…

Suggested fix: Re-run a road-network check for this location once the data service is available, ideally with the specific street name the reporter believes is missing.

  • · Reverse geocode near 37.4220, -122.0841 showing mapped Google campus POIs and addresses
  • · Overpass road-network query attempts (service returned errors, no data retrieved)
AnsweredPlace closed#0b036010 · 30 days ago
near Wullersdorf, Lower Austria(48.625, 16.149)
Agent diagnosisNeeds evidenceanswered in 7 min

The pin for this report sits in open farmland between the villages of Wullersdorf and Oberstinkenbrunn, with no named business or venue currently mapped at that exact spot. Our map data service could not be queried for business listings at the time of this check, so we cannot yet confirm which place the report refers to. Further review is needed once detailed map data can be pulled for this spot.

Suggested fix: Ask the reporter to confirm the business name or re-pin the exact location so the correct POI can be checked and marked closed if warranted.

  • · Reverse geocode: nearest POIs are a fire station roughly 960m away and a church over 1km away, nothing at the reported…
  • · Satellite tile reference for the area (s2-2026_Q1 archive, zoom 13)
AnsweredOther#2a7d2570 · 59 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 · 59 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 · 59 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 · 97 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 · 108 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.