Your First OpenStreetMap Edit, From the Street
At a familiar street corner, first-time OpenStreetMap contributors take one verifiable on-the-ground task, preview the change, and make their first edit.
People making their first OpenStreetMap edit often stand at a familiar street corner but do not know which details are reliable enough to add to the map. On opening the app, they choose something they can personally verify in front of them: a shop entrance, a renamed sign, or a newly opened pedestrian passage.
Using the user’s location and missing map information, the app assigns one small task and explains what to check—and what not to guess. The task card includes only the fields needed for that edit and may ask the user to photograph a sign or confirm an entrance’s direction, rather than overwhelming a newcomer with complex mapping rules.
Before submission, the proposed change is overlaid on the original map: which side the entrance will appear on, how the name will display, and whether a duplicate place already exists nearby. Only after confirming does the user sign in and submit. They can then see whether their first edit is under review or has been accepted.
The initial scope is limited to places, entrances, and passages that can be verified on foot. It excludes edits requiring specialist sources, such as boundary disputes and road restrictions. The goal is to shrink a first contribution into one small task completed on the street, with a visible result by the time the user gets home.
Why now
On September 12, a tutorial for completing a first OpenStreetMap edit appeared on Hacker News, and its September 14 snapshot ranked it No. 1. When tutorial-driven newcomers reach a familiar street corner, they may be especially likely to need help judging which details in front of them are safe to add to the map.
The case against
Putting an entrance on the wrong side of a building can send later map users the wrong way, while same-name shops can be mistakenly created as duplicate places. Avoiding these errors requires reading nearby objects and handling location drift, so a task card cannot be just a form. On-site photos also create privacy and retention burdens—especially when bystanders appear—and must not be uploaded by default. If the preview and the object actually written do not match, newcomers will find errors even harder to spot. The product must also handle conflicts after someone else edits first, and explain comments or changes that may appear after upload. If these steps are not handled well, a simple task can create a false sense of certainty.