Navigation that optimises for the road instead of the arrival time, running on hardware in the house, with no subscription and no account.
A tōge is the road over the ridge: the part of the journey that exists because the mountain is in the way, and which riders take precisely for that reason. It's a compound character that means, literally, "up-down-mountain."
It was chosen over a more analytically "correct" shortlist name. The drift-culture association was raised, weighed, and accepted: the mark is worth more than the caution.
Commercial navigation is built around a single objective: minimise time. That is exactly the wrong objective on a motorcycle on a Sunday. The good road is the slow one (bends, elevation, no lorries), and no mainstream router will choose it for you.
The apps that do serve riders charge a yearly subscription, hold the route library on someone else's servers, and can change terms at any point. Tōge is the answer to "what would it take to just own this?"
The whole routing engine runs on a small box at home. No per-request API bill, no rate limit, no account, no telemetry leaving the house. The custom route profiles are text files that can be tuned by hand rather than settings someone else chose.
Two routing profiles: one for the car, tuned for fast recalculation while moving; one for the bike, which actively scores bends and rewards them instead of penalising them.
Speed on a 240° dial with the current limit marked directly on the arc, so "am I over?" is a glance at a shape, not a comparison of two numbers.
The next turn and the one after it, on separate cards. The follow-up move is the one that catches you out; it gets its own real estate.
Speed limits as the actual roundel, motorway exits as the actual sign. Recognition beats reading when you're moving.
A rider-set tank range that counts down as you ride, so the fuel question answers itself before it becomes urgent.
Two full colour schemes that switch on a sun clock, not a manual toggle. If it looks dark, it's probably just the hour.
The brand was locked in a written spec before a single colour went into the app, and the app was then checked against it by an automated harness that reads the rendered values back out of the running page, because a colour that only exists in the stylesheet isn't a colour the rider sees.
The obvious assumption about self-hosting a country-scale road graph is that it needs an enormous amount of memory, and that adding neighbouring countries means buying hardware. That assumption is wrong in a useful way.
The graph is memory-mapped, so serving it runs on a small heap and lets the operating system's page cache do the work: a whole country's road network sits in a few hundred megabytes on disk. The heavy memory use is a one-time preparation step when the graph is first built. Which means the expensive part can be done anywhere and the result copied across, or skipped entirely at the cost of slightly slower queries that a single user will never notice.
Separating build cost from serving cost turned "you need a hardware upgrade" into "you need ninety seconds and a coffee."
What works: routing on both profiles, live turn-by-turn with the full instrument set, both liveries, geocoding, and an automated test harness that passes end to end against the real running app.
Map data © OpenStreetMap contributors. Routing by GraphHopper. Geocoding via Nominatim, rate-limited and properly identified. None of this is possible without them, and none of it is scraped.