Ranker
A better answer to “where should we eat?”Trip planning: finding stops along a route.
Compare food spots by the things that matter to you: price, ratings, review evidence, and the trip to get there.A closer look at Ranker’s Trip Stops workspace: finding stops along a drive, measuring detours, and planning an itinerary within an API budget. Food search and its ranking model are covered separately below.
RuntimeFor Trip Stops, Google Places supplies candidate stops to the browser. A Cloudflare Worker requests road data from Google Routes. Route sampling, deduplication, and stop comparison run locally.
Trip planning · Trip Stops workspace
How trip planning works.
- 01Get the base routePlaces + RoutesEndpoints, geometry, time
- 02Search along itBrowser → Places≤3 areas · ≤6 results each
- 03Deduplicate & capLocal computation≤12 unique Place IDs
- 04Measure detoursWorker → Routes2 matrices · 2N elements
- 05Filter & compareLocal computationNo request to re-sort
- 06Route chosen stopsIn development1–3 stops · explicit action
Step 01 · Places + Routes
Get the base route
Submitted endpoint searches use Google Places; entered coordinates skip that lookup. Find routes sends a request through the Worker to Google Routes and returns alternatives with distance, duration, and a polyline.
- API work
- Endpoint lookups + one Compute Routes request on a cache miss.
- Tradeoff
- Keep the selected direct route as the baseline instead of requesting it again for each stop.
Step 02 · Browser → Places
Search along it
The browser samples up to three points by distance along the selected polyline. Each Places Text Search covers a five-mile area. Without geometry, the sampling uses a labeled straight-line approximation.
- API work
- Up to three search requests and 18 raw results per Trip discovery action.
- Tradeoff
- Bounded coverage controls requests but can miss good stops between sampled areas.
Step 03 · Local computation
Deduplicate & cap
Places with the same Google Place ID merge. A round-robin pass takes candidates from each sampled area until 12 remain; invalid or out-of-radius coordinates are excluded.
- API work
- No provider request.
- Tradeoff
- Preserves geographic spread. These are not guaranteed to be the best 12 stops on the entire drive.
Step 04 · Worker → Routes
Measure detours
One matrix measures origin → each stop; another measures each stop → destination. Added time is max(0, both legs − selected baseline). The Worker validates the request and retains the server key.
- API work
- For 12 candidates: 2 requests containing 24 elements, before retries or cache hits.
- Tradeoff
- Each stop is evaluated independently. The legs may follow different roads from the selected baseline.
Step 05 · Local computation
Filter & compare
Trip Stops sorts by added driving minutes, road miles, or rating. Detour limits use unrounded road evidence; fallback estimates cannot pass an active limit.
- API work
- Sorting and filtering reuse loaded stop data.
- Tradeoff
- A useful single-stop score does not establish the best combination of several stops.
Step 06 · In development
Route chosen stops
The itinerary code re-fetches each chosen Place ID to confirm its location, then requests one combined route in the user’s order. User-entered visit time is added after the driving calculation.
- API work
- Up to 3 Place lookups + 1 Compute Routes request on a route-cache miss.
- Tradeoff
- Manual ordering keeps the request bounded. Automatic selection and reordering are not implemented.
Places requests run in the browser with a restricted browser key. Routes requests pass through the Cloudflare Worker with a separate server key. The three-stop itinerary is in development; the diagram follows the current source, not a new production verification.
Trip planning · request budget · no live calls
Two requests can still mean 24 elements.
Google bills Route Matrix by origin–destination element. Batching reduces HTTP overhead; reducing the number of measured legs reduces the element count. Google’s billing definition ↗
1 × 12 outbound + 12 × 1 inbound = 24 elements.
Trip Stops matrix work only, with a selected baseline. Excludes Places searches, endpoint lookups, map loads, base-route and itinerary requests. Retries are requested work, not a claim about charges for failed responses. No dollar estimate.
| Control | Saved work | Limit |
|---|---|---|
| 3 search areas; 12 candidates | Caps search calls and detour measurements. | Sampling can miss better stops, especially on a long route. |
| Exact-request route cache | Reuses complete responses for the same request body. | No per-leg reuse across changed batches, no timed expiry, and no shared cache across users. |
| Explicit fields and route options | Matrix calls omit toll pricing; route requests use TRAFFIC_UNAWARE. | Times do not reflect live traffic. Detailed routes request tolls, and requested features/fields affect billing. |
| Bounded retries and quotas | A transient matrix failure gets at most one retry; Worker limits and Google quotas constrain use. | The UI’s 12-stop cap is not a global spend ceiling. Billing-triggered shutdown can lag. |
Field selection affects the work requested and can affect billing. Google’s field-mask guidance ↗. Route caching is keyed by the entire request; an identical route-cache hit does not make a fresh Places search or itinerary refresh free.
Trip planning · proposed optimization
Choosing several stops is a different problem.
Individual detours do not add: O → A → D and O → B → D do not determine O → A → B → D. Stops interact through order, visit duration, opening hours, and the trip’s time limit.
This is a search-space count, not a count of current API calls.
- Prune before requesting more roads. Use route position, distance, category needs, and time budget to discard unlikely combinations. Cheap estimates can eliminate a genuinely useful detour.
- Evaluate a bounded set of plans. Try a small beam search or insertion heuristic using available directed road legs, then verify a few complete itineraries. This trades guaranteed optimality for a fixed evaluation budget.
- Reuse legs deliberately. A per-leg cache could preserve unchanged measurements when a stop is added. It needs keys for direction and route options, freshness rules, and a provider-policy review before implementation.
The current itinerary follows the user’s order and makes one explicit combined-route request. It does not search these combinations, verify opening hours, or optimize automatically.
Food search · data acquisition
Food builds Dish, Cuisine, or Restaurant queries, with at most six terms and 12 search requests across its search areas. Search returns IDs, coordinates, ratings, review counts, and a price tier. The tier becomes a meal-price estimate—not a menu quote.
Phone numbers, websites, and opening hours load only for the selected restaurant. The detail cache holds up to 100 Place IDs and shares concurrent requests for the same ID. These caches are separate from the Trip itinerary’s explicit Place ID refresh.
Food search · scoring & personal edits
Put unlike inputs on one scale.
Price and rating map to 0–1. Review evidence uses 1 − 0.5^(count / 500); 500 reviews gives 0.5, 1,000 gives 0.75. Travel uses 1 / (1 + minutes / 10). The final score is their weighted average × 100.
Review count measures evidence volume. It is not another rating or a probability of quality.
Separate scoring from fetching.
Changing weights recalculates the loaded results. Place discovery and route evaluation require submitted actions. A missing route contributes neither points nor weight; the result is marked provisional.
This avoids another provider request for each adjustment, but cached results can become stale.
Preserve edits during refresh.
mergeRefreshedRestaurant merges provider fields, then restores a whitelist of user-owned fields and the meal-price source. updateUserFields accepts only that whitelist.
A refresh can update the rating without replacing your lunch price or notes. Browser-local storage still limits cross-device use.
Worked example
Three known factors, one missing route.
Assume equal weights and a normalized value of 0.5 for each known factor.
price = rating = reviews = 0.5
travel = unavailable
Including a zero: 100 × 1.5 / 4 = 37.5
Excluding travel: 100 × 1.5 / 3 = 50.0Ranker returns 50 and marks it provisional. Keeping the missing factor in the denominator would penalize an unknown trip. The order may change when route data arrives.
Tests & limits
- Repository tests cover route-area sampling, Place ID deduplication, candidate caps, matrix batching, selected-baseline reuse, exact-request caching, and bounded retries.
- Itinerary tests cover stop limits, incomplete route legs, stale results, and request deadlines. That work package is still in progress.
Current source was inspected; Ranker’s full suite and production deployment were not rechecked for this page. The diagram and request counter make no Google calls.
Source files & authorship
tripStopsService.js; googlePlacesProvider.js; googleRoutesProvider.js; placeDetailsService.js; routeApi.js; tripItineraryService.js; GOODEATS-EWP-028. Inspected 29 October 2026. The three-stop itinerary is in development; automatic selection and ordering are proposals.
Product direction: Jaxson Mercer. Development uses AI assistance.
Screenshots
Where it started
What makes a place worth the trip?
I wanted to know the good food spots around me, but a list of ratings only answered part of the question. Ranker started as a way to bring cost, confidence, and travel into the same decision—and let me decide how much each one matters.
Sometimes the right answer is nearby and inexpensive. Other times, a longer trip is worth it. Ranker makes those priorities something you can change, instead of leaving you to guess what a list of stars is optimizing for.
Good depends on what matters today.
In use
From “what’s nearby?” to a shortlist.
- 01
Set the context.
Choose Food for a meal near a location or along a drive. Trip Stops is a separate workspace for places such as coffee shops, parks, and attractions.
See planning modes - 02
Choose what matters.
Set food preferences, then compare price, rating, review evidence, and travel. Adjust priorities using the results already loaded.
See food preferences - 03
Build your own knowledge.
Save a place deliberately. Keep a lunch price, dish notes, or a favorite alongside the provider’s information, so your experience carries into the next decision.
Try the idea · fictional places
Same three places.
Different kind of day.
Change your priority and watch the order. The example uses Ranker’s scoring model with invented places and fixed data.
Pine Street Tacos leads with budget first.
- 0166.9 / 100
Pine Street Tacos
$9 lunch · 4.1 stars
180 reviews · 18 min away- Price
53.3 points 53.3- Rating
6.0 points 6.0- Review evidence
2.2 points 2.2- Travel
5.4 points 5.4
- 0261.8 / 100
Corner Table
$14 lunch · 4.4 stars
450 reviews · 3 min away- Price
36.7 points 36.7- Rating
9.0 points 9.0- Review evidence
4.6 points 4.6- Travel
11.5 points 11.5
- 0338.9 / 100
Juniper Kitchen
$22 lunch · 4.9 stars
1,200 reviews · 12 min away- Price
10.0 points 10.0- Rating
14.0 points 14.0- Review evidence
8.1 points 8.1- Travel
6.8 points 6.8
Bars show each factor’s contribution to the total score. Review evidence measures volume, not the chance that a place is good.
How the example works
The four weights are price / rating / review evidence / travel. Budget first uses 12 / 3 / 2 / 3; Ratings first uses 2 / 14 / 3 / 1; Short trip uses 2 / 3 / 2 / 13.
Price is normalized over $7–$25, rating over 3.5–5 stars. Review evidence is 1 − 0.5^(reviews / 500). Travel is 1 / (1 + minutes / 10). The weighted average is scaled to 100.
When routes are unavailable, travel contributes no points and its weight leaves the denominator. The remaining factors are recalculated and every result is provisional.
Who it’s for
For someone deciding where to eat—or looking for a worthwhile stop on a drive—who wants more control than a single default sort.
The next question
The continuing question is whether the comparison helps someone make a decision faster. Clearer explanations and honest gaps in the data matter more than presenting every result as certain.
Available now
Ranker is available publicly. Saved places and trips belong to the browser you use.