Skip to content

How a route is built

A route is built from three things: the profile from onboarding (interests, pace, crowd tolerance, budget, transport, meals, travel context), a start point (GPS, a manually picked place or the remembered city) and time (how many hours, starting when). Nothing else is required — not having an account does not limit generation itself.

  1. The search area depends on time and transport: three hours on foot is a radius of about 2 km; a bike triples it, public transport multiplies it by five. Places outside the circle are dropped even when they fit the bounding box.
  2. Scoring adds five weighted terms per place: interest match, narrative strength (how good a story can be told about it), crowd level at that time of day, uniqueness (how rarely it has been served to others) and a gamification bonus. A distance penalty and a budget fit are applied on top (ticketed places lose points on a “mostly free” budget).
  3. Hard filters are not up for scoring: a place is never scheduled inside the hours it should not be visited; the first stop is at most 800 m from the start (1.5 km once the user has a visit history).
  4. The number of stops comes from a time × transport table (e.g. 3 h on foot = 4–5 places). When there are too few candidates the generator widens the area by half, once; if that is still not enough the route ships as reduced and the app says so.

Stops are sequenced from the start with a dwell time and the walk to the next one. Around 60–75 % of the route the generator places the peak stop — the place with the strongest narrative, meant as the climax. Long routes (e.g. 12 h by public transport) get two meal stops from the reserve. If it rains mid-route, an indoor place wins ties.

The same profile at the same hour does not get the same route twice: the generator adds a small random spread (a seed). For tests the seed can be pinned — then the route is identical stop for stop. Places the user has already visited or rejected are excluded by the app itself, which passes the exclusion list on the next generation.

  • It does not know transit timetables: travel times come from an average speed plus a fixed transfer overhead; hops under 800 m are always priced on foot.
  • It does not book tickets — it only shows that one is needed and an indicative price.
  • Without a Google Routes key, travel times come from the fallback model, not from maps (the pricing_source field in the response says which).