Franchise and brand queries
A franchise query names a specific chain or brand. The user doesn't want the nearest restaurant โ they want the nearest McDonalds. The brand name is the query, and the geocoder's job is to resolve it to one or more specific locations.
What franchise queries look likeโ
| Query | Implicit meaning |
|---|---|
Walmart | Nearest Walmart store |
McDonalds | Nearest McDonalds restaurant |
Hilton | Nearest Hilton hotel |
Starbucks | Nearest Starbucks coffee shop |
7-Eleven | Nearest 7-Eleven convenience store |
Home Depot near Springfield, IL | Nearest Home Depot to a specific place |
Walmart Supercenter vs Walmart Neighborhood Market | A specific sub-brand of the franchise |
McDonalds with PlayPlace | A franchise location with a specific amenity |
Franchise queries have three components: a brand name, an optional sub-brand or feature filter, and an optional location constraint. The brand name is the hard part โ it may not match what the franchise calls itself, and it varies by region.
The brand-name problemโ
"McDonalds" is the official brand name. Users also search for:
McDonalds(correct spelling)McDonald's(possessive, correct per corporate branding)Mcdonalds(incorrect but common)Mickey D's(slang, US)Macca's(slang, Australia)ใใฏใใใซใ(makudonarudo, Japan โ full name)ใใฏใ(makudo, Japan โ abbreviated, Kansai region)McDo(abbreviated, France/Quebec)Mek(abbreviated, German-speaking countries)
A geocoder that only matches "McDonald's" against an exact-string index will miss every slang and regional variant. A geocoder that matches all variants requires an alias table mapping user-facing terms to brand identifiers.
You might expect the geocoder to translate these the way a dictionary maps one language to another, turning "Macca's" into "McDonald's" before it searches. That instinct misreads the problem. "Macca's" in Australia, "Mickey D's" in the US, and "ใใฏใ" in Kansai are all names real people use for the same golden arches. The alias table codifies that web of names so any one of them reaches the brand identifier. Search McDonald's or Maccas, and the geocoder knows you mean the same chain.
The sub-brand problemโ
Franchises have sub-brands that differ in meaningful ways:
- Walmart has Walmart Supercenter (full grocery), Walmart Discount Store (general merchandise, no grocery), Walmart Neighborhood Market (grocery-only, smaller footprint), and Sam's Club (warehouse membership).
- Hilton has Hilton Hotels & Resorts (full-service), Hilton Garden Inn (mid-scale), Hampton by Hilton (budget), Homewood Suites (extended stay), and several others.
- Starbucks has company-operated stores, licensed stores (in airports, hotels, grocery stores), and Starbucks Reserve Roastery (premium, limited locations).
A query for Walmart could mean any of the sub-brands. A query for Walmart Supercenter is specific. The geocoder should return the nearest Supercenter for the specific query and the nearest any-Walmart for the generic query. This requires the POI index to include sub-brand classification.
The location-constraint problemโ
Walmart near Springfield, IL requires two operations:
- Resolve the location constraint (
Springfield, IL) to coordinates or an area. - Find the nearest Walmart to that location.
The location constraint is an address or place name โ the kind of query Mailwoman already handles. The franchise lookup is new. The composition of "parse the location constraint, then query the franchise index near that location" is a two-stage resolver query: resolve the place, then find POIs near it.
This is the same pattern as "gas station near Springfield, IL" (amenity + location constraint) but with a named brand instead of a generic category.
How traditional geocoders handle franchise queriesโ
Google's Places API handles franchise queries through Google's place database. A search for "McDonalds" returns McDonalds locations ranked by proximity and prominence. Google's database includes franchise locations globally, with sub-brand classification (Walmart Supercenter vs Walmart Neighborhood Market) and user-contributed attributes (PlayPlace, drive-through, 24-hour). Google handles spelling variants and some slang through its search model.
Nominatim handles franchise queries by matching the brand name against OSM's name and brand tags. OSM has good coverage of franchise locations in well-mapped areas. However, OSM's brand tagging is inconsistent: some locations are tagged brand=McDonald's, others name=McDonald's, and the relationship between franchise brand and individual location name varies by mapper. Nominatim does not handle slang or regional variants โ Macca's returns nothing unless an Australian mapper tagged a location with alt_name=Macca's.
Pelias indexes franchise locations as part of its OSM and OpenAddresses gazetteers. The same OSM tagging inconsistency applies. Pelias's search matches "McDonalds" against name and brand fields, and its categories parameter can filter by broad types (e.g., food), but it has no brand-alias resolution โ slang and variants don't match unless the exact text appears in the data. Sub-brand classification is not modeled.
What Mailwoman does todayโ
Mailwoman's parser will see Walmart and try to classify it as an address component. A lone brand name with no other tokens is a one-token address โ the parser may classify it as locality (there are towns named Walmart) or venue (the venue classifier exists but is weak). The resolver will search WOF for "Walmart" and return nothing โ WOF does not index franchise locations as venues.
Franchise queries are out of scope for Mailwoman's current architecture, for the same reasons as amenity queries: they require a POI index and a brand alias table. The address parser can handle the location-constraint part (near Springfield, IL) but the franchise lookup requires different infrastructure.
See alsoโ
- Amenity queries โ the generic-category version
- Regional variant queries โ when the same brand has different local names
- Exotic POI overview โ the series index