Last month I wrote about importing six thousand rural dispatch targets out of an old federal dataset like churches, cemeteries, dams, post offices, etc. to fix the small-town coverage gap. That post ended with a confession: the very first dispatch the new system produced sent me to “Armstrong Lake Dam,” which did not exist. There’s barely a lake and there is no dam.

I’ve since deleted that whole database. This post is about why building my own copy of the map was the wrong shape for the problem, what I replaced it with, and how the replacement turns Dispatch Zero into something that both uses and contributes to open map data.

The Problem With Owning a Copy of the Map

The GNIS import worked, in the narrow sense that it put targets on the board. But it had three problems, and they got worse the longer I worked with them.

It was already stale the day I imported it. The file was a 2020 snapshot, pulled from the Internet Archive because the modern dataset had dropped its cultural features. Buildings mostly don’t move, so most of it was fine, but “mostly” is exactly where the Armstrong Lake Dam problems occur. Plus, these public databases are already full of old and outdated references, and many are not even mapped to current standards. There was no way to learn that something got demolished, or was mapped incorrectly, short of driving out to every one of six thousand points or trying to cross-reference them to another dataset.

It was mine to maintain, forever. One state took a custom importer, a feature-class filter, and a name-safety pass. Doing Oregon and Idaho meant running that again. Keeping any of it current meant re-running it against snapshots that no longer get published. I had signed myself up to be the sole maintainer of a private, decaying mirror of data that a hundred thousand strangers were already maintaining better, in public, for free.

It was a one-way street. This is the one that actually changed my mind. When I find a place that isn’t on the map, the painted shed at the edge of town, or the local bridge nobody officially named, importing it into my own database helps exactly one app: mine. The knowledge dies in my Postgres instance. That felt backwards for a project whose entire premise is getting people to go look at real things in the real world.

What I Do Instead: Ask the Live Map, in Tiers

The replacement isn’t a database I own. It’s a query I run against OpenStreetMap at the moment you request a dispatch, and it’s structured as a ladder. Each rung widens the net; the first rung that comes back with a usable, unvisited place wins:

• Your radius, strict OSM. The good stuff first like murals, sculptures, memorials, historic sites, and viewpoints within a couple of kilometers.
• Five kilometers, strict OSM. Same art-first categories, wider circle.
• Five kilometers, broad OSM. Now the net opens up: churches, libraries, cemeteries, parks, peaks. The everyday landmarks of a small town.
• Five kilometers, Wikipedia geosearch. A different source entirely, for the places that are notable enough to have an article but tagged sparsely on the map.
• Ten kilometers, broad OSM. A wider sweep for genuinely rural requests.
• Ten kilometers, local. The last resort, and the interesting one, I’ll come back to it.

Additionally, we now give the user a choice of dispatches rather than a single one, the same ladder runs, but instead of stopping at the first hit it accumulates down the rungs, it continues until it has three options, closest art first, then whatever else is near.

That was the fix for what I started calling the airport problem. Because at a certain point my nearest landmark was a small agricultural airstrip, where the marker was too far into the airfield to successfully gather, I was effectively locked out of doing addiontal missions unless I got far enough away from the airport to get a different landmark. Now that there are three choices presented, I can simply choose the one I want to do and avoid a problematic location.

Why This Is More Reliable, Not Just Cleaner

It would be easy to frame this as me tidying up, but the reliability gain is real and it comes from three places.

The data heals itself. When a building on OpenStreetMap gets demolished in the real world, a mapper eventually removes it, usually someone local. I don’t chase a snapshot anymore; I ask the current map every time. The Armstrong Lake Dam failure mode doesn’t get impossible, but it gets much rarer, and when it does happen it’s a shared error that someone else is also incentivized to fix.

Two sources don’t become two targets. A place that shows up in both OSM and Wikipedia used to risk appearing twice. Discovery now merges candidates by their significant name tokens, the words left after you strip filler and the category word. “Harrington Opera House” and “Opera House (Harrington)” collapse into one place; “First Presbyterian” and “First Baptist” stay correctly distinct. You rarely get sent to the same spot twice unless it does by multiple names.

A bad upstream day degrades instead of failing. If the system times out on one rung, that rung just logs a warning and the ladder tries the next one. A single flaky dependency can’t take the whole dispatch down, the worst case is a slightly wider search, not an error screen.

So What’s Left in the “Local” Tier?

That last rung used to be the six-thousand-row GNIS import. It isn’t anymore, I retired the statewide import from the live path completely. What lives there now is just community submissions: places a real person stood in front of, tapped “Report a Point of Interest,” and told me about, because no public dataset knew they existed yet.

Those places are dispatchable, after manual review, straight out of the local tier, so others may visit the locally added landmarks as well. But that’s not where they’re meant to stay, quality submissions may be approved for submission to OSM.

Closing the Loop: Contributing Back to OSM

Here’s the part that made all of this worth doing. Once Dispatch Zero treats OpenStreetMap as the source of truth instead of a thing to scrape, the natural endpoint for a community submission isn’t my database, it’s the database. The shared one.

So a submitted place moves through a review queue where a quality and well documented location can be published straight to OpenStreetMap under the Dispatch Zero account: a real node, on the real map, that every other app and person now benefits from. Before it publishes, a preflight re-checks the area against live OSM, so I don’t add something that already exists, and the location information is checked for accuracy and quality. The moment a place lands on OSM, my own local tier stops mattering for it, the OSM tiers up top cover it now, for me and for everyone else.

Since this is not a thing to automate carelessly, every submitted location is manually reviewed. The publishing pipeline is built and running right now, it assembles the exact changeset and records it, and I’m reviewing those by hand before I let it write for real, with a small daily cap on top of that to prevent abuse. It is a slow process, but that is probably the correct speed for editing a map that millions of people rely on. But the direction is set: the app that sends you out to look at the world can now help describe that world a little better for the next person, whatever app they’re using.

That’s the whole reframe. I stopped trying to own a worse copy of the map, and started contributing to the good one.

Try It

https://dispatchzero.ataary.com

Still very much in development. Sign up, request a dispatch, and if you know a place the map is missing, report it, and it might just end up on OpenStreetMap.