Your First OpenStreetMap Edit, From the Street

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. ^S1 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.

Newcomers who have just learned they can edit OpenStreetMap and happen to be passing a familiar shop. They can see that the sign has changed but do not know whether to update an existing place or create a new one. While on site, they can verify the name and entrance; at home, relying on memory makes guessing more likely. The task should first help them confirm the object and evidence, then decide whether to submit—not push them to complete a first contribution.

Start by reading nearby OSM objects and generate only candidate tasks that can be verified on site, such as shop names and entrance locations. The OSM API v0.6 can read map data by area; writing requires OAuth 2.0 authorization and an associated changeset. ^S2 Task cards require users to personally verify a sign or entrance. Photos remain on the device for self-checking and are not uploaded publicly by default. Before submitting, overlay the proposed location and list nearby objects with the same name. When uncertain, users can leave rather than have the product guess for them. The first version should not draw new passages, to avoid mistaking path connectivity for a line. After submission, show the changeset and any subsequent comments; do not call a successful upload “approved.” ^S2

Find the first participants through OSM communities already running neighborhood walking-mapping events, rather than through broad map-product advertising. Bring a task list limited to one neighborhood and ask event organizers to observe where newcomers quit or choose the wrong object. Afterward, publish reviewable usability issues and the resulting revisions, then invite participants to revisit their own changesets. Blur faces and personal information in on-site photos, and do not treat contribution counts as proof of impact.

StreetCompleteGoogle

StreetComplete already highlights nearby questions that need on-the-ground verification. After users answer simple questions, the app uploads edits through their OSM accounts; it is not missing a product for “small street-level tasks.” ^S3 If this card merely rewrites missing fields as questions, it will be hard to differentiate. A gap worth testing is the judgment before a first submission: can users clearly see which shop they selected, where the edit will land, and whether the same place already exists nearby? Showing the original map alongside the proposed change may be more useful than adding more tasks. This is still a product trade-off, not a claim that StreetComplete cannot make these edits.

Every DoorGoogle

Every Door already lets people view nearby shops, maintain place information, and add building entrances from a phone. It also supports preloaded maps and offline work, so “editing shops and entrances on the street” cannot be presented as a new opportunity. ^S4 Its quick guide organizes editing into different modes, requiring users to switch by object. ^S4 A new product could narrow the first contribution further: choose one thing visible in front of you, show only the information required for that edit, then have the user verify its placement and nearby objects. The trade-off is that experienced contributors may find the process too slow, and complex places may not fit into a single task card at all. Early tests should compare whether newcomers choose the wrong object less often, rather than which tool supports more edit types.

Free for individual on-the-ground edits. Charge community organizations running neighborhood mapping events a one-time service fee for event task setup and participant training; do not charge for the right to submit map edits or for supposed “approval.”

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. ^S2 If these steps are not handled well, a simple task can create a false sense of certainty.