Editorial Policy

SimpleMapLab is run by a small independent team. There is no advertiser relationship that shapes content, and no “sponsored partner” section. This page describes how content is researched, written, fact-checked, and corrected; how AI is used (and where it isn't); and how editorial independence is maintained against the site's commercial backbone (display ads).

Editorial mission

SimpleMapLab exists to make public-domain geographic data accessible to non-specialists through fast, free, reproducible tools and well-sourced studies. Editorial decisions are made against four commitments:

1. Specificity over vagueness. Where data exists for a real number, we use it. Where it doesn't, we say so explicitly.
2. Sourced over asserted. Every factual claim traces to a public dataset, an official document, or a cited methodology. Anything we can't source, we don't state.
3. Transparent over polished. Limitations, uncertainty bounds, and methodology choices are disclosed in the same place the finding is stated — not buried in fine print.
4. Useful over viral. A page exists because it answers a real question. We won't add a tool, a study, or a blog post if it's only there for keyword coverage.

Who writes the content

Every page of editorial copy is researched and edited by the SimpleMapLab team. There is no contributor program, no freelance pool, and no “guest-posted” content. Long-form prose (tool descriptions, blog posts, study narratives) is drafted with the assistance of large language models — see the AI disclosure section below — and then reviewed, fact-checked, and edited before publication.

How we write and verify content

Editorial work on SimpleMapLab follows a standard research → outline → draft → fact-check → edit → publish workflow. Drafts may use modern writing tools at the drafting stage. Every fact, statistic, place name, distance, demographic, and source is then verified against primary data before publication, and every page is reviewed by the editorial team before going live.

Numbers, boundaries, distances, and demographics are not generated by writing tools — they come from public datasets (Census Bureau, USGS, OpenStreetMap, Natural Earth, Copernicus DEM, IANA tz database) and from deterministic TypeScript pipelines whose outputs are reproducible from those public sources. The data download attached to each study is generated by those scripts, not by prose generation.

Where human judgment is non-negotiable: which study to publish, the framing of the headline finding, the methodology disclosure, corrections, press responses, and what to leave out. The editorial team owns every claim that ships.

Sourcing standards

Every factual claim on the site must be traceable to one of these source classes:

• Official US government datasets: Census Bureau (population, ZCTA, boundaries), USGS (elevation, place names), NPS (National Parks), CMS (hospitals), NCES (schools), DOT/BTS (transportation), NHC (hurricanes).
• Internationally maintained open datasets: Natural Earth (world boundaries), OpenStreetMap (road network, addresses, POIs), Copernicus DEM (elevation), IANA tz database (time zones).
• Open-source software documentation: Valhalla (routing), MapLibre (rendering), d3-geo (projections). Where we describe how a calculation works, we cite the project documentation.
• Peer-reviewed or government-published methodology: USDA Food Access Research Atlas conventions, retail trade-area academic literature, Census centroid methodology.

We don't source from listicle blogs, Reddit threads, Quora answers, or AI summaries of any of the above. If a fact requires citation, we cite the primary source directly.

Editorial process per content type

Tool pages (66 currently published)

1. Identify the user task the tool addresses (what someone is searching for when they need this tool).
2. Build the tool — the calculation is the source of truth, not the prose.
3. Write the "How to use this tool" section and 4-6 worked examples with named places + specific numbers.
4. Write the methodology block — the formula, the data source, the accuracy bound — citing our central Methodology page where relevant.
5. Write the FAQ (typically 8-12 questions) and the technical reference table.
6. Cross-link to related tools.
7. Test the tool end-to-end on desktop + mobile before publishing.

Open-data studies (3 currently published)

1. Identify a real research question worth answering with public data.
2. Write the computation pipeline as a TypeScript script in scripts/ — the script outputs a deterministic JSON file from public inputs.
3. Sanity-check the top entries against an independent source (Wikipedia, Census official tables, the relevant agency's reports).
4. Write the hub page with the headline finding, ranked tables, per-state grid, and methodology.
5. Write the 50 per-state spokes. The 10 most pitch-worthy spokes get hand-written historical context; the remainder use data-driven differentiated paragraphs.
6. Publish the dataset (JSON + CSV) under CC-BY 4.0, with the contentUrl in the Schema.org Dataset markup.
7. Verify the headline finding holds up after reviewing the top-20 entries one more time.

Blog posts (8 long-form posts)

Each blog post is the canonical answer to a specific question (e.g., "how many counties in each US state," "the largest US counties by area"). Posts are factual and topical, not listicles. Each one is built to be the definitive resource for that question with sourced data tables and internal links to the relevant tools. Posts are reviewed for accuracy on roughly a 12-month cadence and at any time a reader reports a possible error.

What we don't do

• We don't fabricate data. If we can't source a number, we don't state it.
• We don't present approximations as exact. Estimates carry "approximately" or "~"; rounding is disclosed.
• We don't copy from other sites. Prose is original; data is from primary sources.
• We don't publish sponsored content. Display advertising runs on tool, blog, and study pages; sponsored articles, "guest posts," native-ad placements, and paid links are declined.
• We don't invent data. Every number on the site is traceable to a public source.
• We don't scrape protected sites. Every data source is openly licensed (CC-BY, ODbL, MIT, public domain) or an officially published government dataset.
• We don't hide methodology behind a paywall. Every formula, source, and limitation is documented on the Methodology page.
• We don't game search by adding location names where they don't belong. A page about "Costco access" talks about Costco; a page about "state capitals" talks about state capitals. We don't silently inject 50 state names per page for ranking.

Corrections policy

Errors get found. When a reader, a journalist, or our own re-review surfaces a mistake, the workflow is:

1. Verify. Confirm the error against the underlying source data. Sometimes "errors" turn out to be intentional methodology choices we should explain better; sometimes they're real bugs.
2. Fix at the source. Update the data file, the script, or the prose — whichever is the root cause. Rerun any dependent pipelines.
3. Publish the fix. Rebuild the affected pages and deploy.
4. Note the correction. Add an "Updated: corrected X on date" line at the bottom of the affected page. For headline-grabbing corrections (top-line study finding changing), also publish a brief note on the site's changelog and email anyone we're aware of who cited the affected number.
5. Reply to the reporter. Thank them, explain what we fixed, and what was wrong.

To report a possible correction: email hello@simplemaplab.comwith "Correction:" in the subject line, the page URL, the value you think is wrong, and (ideally) a source. We respond within 1–3 business days; fixes typically publish within 48 hours of confirmation.

Editorial independence and advertising

SimpleMapLab is supported by display advertising. Display advertising is content-blind: ads appear in fixed slots on tool, blog, and study pages based on the network's targeting, not on what the page says. The SimpleMapLab team has no editorial relationship with individual advertisers, no advance knowledge of which ads will run on which pages, and no incentive to write content favourable to specific advertiser categories.

Concretely, this means:

• No content on SimpleMapLab is paid for by an advertiser.
• No tool design, study scope, or blog topic is chosen because an advertiser asked for it.
• No factual claim is shaped to favour or disfavour an advertiser category.
• Editorial decisions about what to publish, what to retract, and how to correct are made independent of advertising performance.

Affiliate and partnership disclosure

SimpleMapLab does not currently run affiliate links, sponsored content, or paid partnerships. If that ever changes — for example, an affiliate relationship with a hardware or software partner relevant to the site's topic — this section will be updated, the affiliate links will be marked with the recommended rel="sponsored" attribute, and the page itself will carry an inline disclosure.

Conflict of interest

The SimpleMapLab team has no financial interest in any product, service, or organisation discussed on the site beyond the open-source software dependencies described on the About page. SimpleMapLab is not affiliated with the US Census Bureau, OpenStreetMap Foundation, the National Park Service, USGS, Google, or any other agency or provider whose data we use. The tools and studies use public data but are independent of and not endorsed by those data providers.

Sources and external links

When we cite an external source — a government agency, an open-source project, an academic paper — we link directly to the primary source, not to an aggregator or summary. Outbound links open in a new tab with rel="noopener" for safety. Outbound links are not affiliate or referral links.

Voice and style

Pages are written to be useful, not breathless. Concrete claims with named places + specific numbers outweigh adjectives. We avoid:

• "Discover the amazing fact that…"
• "Did you know that…"
• "In today's digital world…"
• "Whether you're a student, a researcher, or a curious traveler…"
• Listicle filler ("5 amazing reasons to use a radius map").
• Bait-and-switch headlines whose claim isn't supported in the body.

We try to write like a colleague who knows the data well and is helping you find what you need fast. Specificity is the voice.

Update cadence

• Tool functionality: updated continuously. Bug fixes ship the same day; feature changes ship in batches.
• Census ZIP-population data: updated when new ACS releases are published (annually).
• Map tiles: updated continuously by the OpenStreetMap community via OpenFreeMap.
• Blank maps: regenerated when boundary source data is updated.
• Studies: rerun when the underlying ACS release updates materially or after the next decennial Census (2030). Methodology changes are versioned with a published changelog.
• Blog posts: reviewed for accuracy on a roughly 12-month rolling cadence. Data tables in blog posts are rebuilt from source data at each site build.
• Footer pages: About, Methodology, Editorial, Contact, Privacy, Terms, Disclaimer. Reviewed at least quarterly and on any major site change.

Reader trust signals (how to verify the above)

You don't have to take our word for any of this. Concrete ways to verify:

• Every study has a downloadable dataset. Run your own analysis on the JSON / CSV. If our numbers don't match yours, that's a correction.
• The study computation scripts are committed in the public repo at scripts/compute-*.ts. The code is the methodology.
• Every page has a "Page last reviewed" date in the footer. We update it when we update.
• Outbound links go to primary sources, not aggregators. Click through and verify.
• The Contact page documents response-time commitments by request type. If we miss one, you'll know.

Questions

Questions about how content is produced, sources we use, or how we'd handle a specific edge case: hello@simplemaplab.com, or the Contact page.

Editorial Policy last reviewed: 14 May 2026. Maintained by the SimpleMapLab team. Material changes to this policy will be dated and noted at the top of this page.