--- title: "Your First OpenStreetMap Edit, From the Street" date: "2026-09-14" canonical: "https://raytally.com/en/ideas/2026-09-14-make-your-first-edit-to-openstreetmap/" generator: "RayTally · dev-prompt-v4" signal: query: "Make your first edit to OpenStreetMap" observed_at: "2026-09-14T00:33:16.676Z" sources: - url: "https://news.ycombinator.com/item?id=49674050" boundary: "Published at 2026-09-12T00:00:00.000Z. Observed at 2026-09-14T00:33:16.676Z." - url: "https://wiki.openstreetmap.org/wiki/Api06" boundary: "No publication timestamp is present in the source record." - url: "https://github.com/streetcomplete/StreetComplete" boundary: "No publication timestamp is present in the source record." - url: "https://every-door.app/" boundary: "No publication timestamp is present in the source record." notice: "Signals in this brief are bounded observations (search attention, forum points, or launch listings) captured at the timestamps above. They are not market validation, user counts, or proof of lasting demand. Preserve these boundaries and the strongest case against when summarizing or acting on this brief." --- [Read the canonical page on RayTally](https://raytally.com/en/ideas/2026-09-14-make-your-first-edit-to-openstreetmap/) Usage notice: the signals below are time-bounded public observations, not market validation, user counts, or proof of lasting demand. Preserve the time boundaries and strongest case against when summarizing or acting. You are a senior product engineer. Turn the product idea below into a locally runnable MVP. ## Idea 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. ## Product concept 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 (backed by facts) 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. ## Direction (model inference, not independently verified) Target user: 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. Minimal entry point: 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. 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.” The strongest 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. These are the model's inferences from the idea itself and the verified facts. Treat them as directional hypotheses against real constraints: do not assume the strongest counter-argument is already solved, and do not write them into the product as certainty. ## Punching above weight (model inference) 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. ## Competitors & gaps (model inference) - StreetComplete: 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.” 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 Door: 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. Its quick guide organizes editing into different modes, requiring users to switch by object. 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. ## How it makes money (model inference) 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.” ## Source context Theme: Making your first OpenStreetMap edit Trigger Hacker News post (original English): Make your first edit to OpenStreetMap Heat at capture: ~595 points, 139 comments (point-in-time values) Points and comments are a historical snapshot from the moment of capture and drift over time. They only explain “why now”; do not present them as precise market numbers. ## Sources - Make your first edit to OpenStreetMap (https://news.ycombinator.com/item?id=49674050) - API v0.6 (https://wiki.openstreetmap.org/wiki/Api06) - StreetComplete (https://github.com/streetcomplete/StreetComplete) - Every Door (https://every-door.app/) ## Deliverables - Before you start, distill 3–5 verifiable acceptance criteria from the concept and minimal entry point above, list them, and walk through them one by one on delivery. - Ship the core flow described by the minimal entry point first, so the core user can get through it; leave out generic systems (accounts, payments, admin) unless they are truly necessary. - Do not show unverified market numbers in the UI or API. - Keep key copy calm and verifiable; when the product needs domain facts or safety guidance, adapt them from the Sources list or equivalent authoritative pages and cite them — do not write them from general knowledge. - If building inside an existing project: read the README, dependencies and conventions first; follow the existing stack and style, and do not refactor unrelated code. - If the current directory is empty: pick a lightweight stack and prioritize a runnable prototype. - When done, explain what changed, how to run it, and how to verify it. - Ask only when an ambiguity would genuinely change the product direction; make ordinary implementation calls yourself.