Methodology & data sources.

1. Primary data source

The restaurant universe on MenuScout is sourced entirely from the OpenStreetMap Overpass API. OpenStreetMap is a global, openly licensed geographic database maintained by a community of contributors. The Overpass API exposes that database for structured querying. We currently cover 104 US cities across 42 states, which yields 1,238 restaurant entries and 118 distinct cuisine tags after normalization.

2. Query design

For each city in our coverage list, we query Overpass for nodes tagged with either amenity=restaurant or amenity=fast_food AND a non-empty cuisine tag, within a radius of roughly 5.5 km of the city center coordinate. The cuisine-tag requirement is deliberate: an entry without a cuisine tag rarely has enough structured information to write a useful directory page, so we exclude it. The 5.5 km radius is a compromise between covering an urban core meaningfully without spilling into adjacent metros.

3. Normalization

Cuisine tags in OpenStreetMap are free-text and inconsistent. A burger spot might be tagged "burger", "burgers", "hamburger", "american;burger", or "fast_food". Our normalization layer maps the most common variants to a single canonical slug and label per cuisine, splits multi-cuisine tags into a primary and a list of secondaries, and falls back to a sensible default when the tag is ambiguous. Street addresses and city names are normalized for slug generation; phone numbers and websites are passed through unchanged so we never accidentally fabricate contact information.

4. Rating and "recommended" logic

OpenStreetMap does not carry restaurant ratings the way a review site does, so our rating is a synthetic signal derived deterministically from the restaurant's stable OSM identifier and tag depth. Restaurants with more complete tagging (full address, phone, website, opening hours) get a small boost, on the rationale that thoroughly tagged entries tend to correspond to operators that pay attention to their public presence. The "recommended" badge is reserved for the top tier of that combined signal and currently flags roughly the strongest one in three entries per city.

This is not a substitute for a curated human rating, and we say so plainly. The signal is intended to give the directory a usable sort order rather than a pretense of editorial endorsement on every single page. Where a city's top picks are hand-reviewed, we will note that on the city page directly.

5. Price tier ($, $$, $$$)

OpenStreetMap occasionally carries a price_range tag, but coverage is thin and the values are inconsistent. We therefore derive price tier from a combination of cuisine type and the presence or absence of tags that correlate with check size. Counter-service chains and traditional fast-food cuisines default to $, full-cuisine independents and established regional chains default to $$, and a small number of higher-end fast-casual operators (typically tagged as fusion or sushi) fall into $$$. The tier is meant as a rough budget anchor, not a precise check estimate.

6. "Open late" detection

The "open late" filter on city and cuisine pages parses the underlying OpenStreetMap opening_hours tag for any closing time of 22:00 or later, or any indication of 24/7 service. The tag follows a structured OSM grammar (for example, "Mo-Su 11:00-22:00") and is parsed conservatively: if we cannot confidently identify a late closing time, the entry is not flagged. Restaurants without any opening_hours tag in OSM are never flagged as open late, even if they actually are.

7. Editorial layer

Every restaurant, city, cuisine, and state page on MenuScout carries a multi-paragraph editorial summary. These summaries are generated by a structured templating engine in lib/text.php that varies opener, menu framing, atmosphere description, value framing, and closing line based on the restaurant's stable OSM identifier. The result is deterministic: the same restaurant always gets the same write-up across refreshes, so the page reads consistently to repeat visitors. Editorial copy is not a substitute for a human review, and we do not represent it as one.

8. Cross-linking and "related resources"

The "Related entries" block in every sidebar lists only internal cross-links: sibling cities in the same state, related cuisines in the same city, and similar restaurants in the same city or cuisine. We do not host external link slots, sponsored placements, or any other form of paid outbound link. The block is computed at render time from the restaurant index, so it always reflects the current dataset.

9. What we do not do

We do not fabricate restaurants, addresses, phone numbers, or hours. We do not invent operating times when the source does not have them. We do not insert outbound links in exchange for payment. If a restaurant page lacks a piece of information, it says so explicitly rather than filling the gap with a guess. Every internal link on the site resolves to a real, fully built page with substantive content.

10. Refresh cadence

The full dataset is re-pulled in batches as we expand coverage to new cities. Individual snapshots are therefore weeks old at any given moment rather than minutes old, which is acceptable for a directory of stable businesses and unacceptable for any real-time question (current wait times, daily specials, today's hours during a holiday). The "Updated" timestamp in the footer of every page reflects the actual file modification time of the restaurant snapshot.

11. Source attribution

Underlying restaurant facts are © OpenStreetMap contributors and are made available under the Open Database License (ODbL). The footer of every MenuScout page carries that attribution. If you reuse data from this site in a derivative product, attribute OpenStreetMap contributors directly rather than MenuScout.