Phase 7b — A ride is planned along the Bike routes, one-way lines their way

Sequence lives in PLAN.md; the live worklist lives in DOD.md. This phase relies on ADR-0011 (Bike routes only, distance and ascent first, the time our own estimate) and amends it four times: the flat speed is the way’s surface class rather than the Bike route’s kind, a riding time ships only once it has passed § 1’s gate, a saved Route keeps its Mode, a schema change here rather than in 7c, and Following in Cycling is on screen from here, its screen kept on and its voice still 7d’s. It relies on ADR-0010 (the router, whose second set of edges phase 7a built), ADR-0001 (a saved Route gains two columns, the first migration since phase 6) and ADR-0008 (the published times are read on the owner’s PC, never by the app). CONTEXT.md is owed nothing: Route, Following and Pace already say what each is in Cycling. Planned with the owner on 2026-11-11.

What closing this phase means. Today a developer build can switch to Cycling and see the Bike routes, but a long press there plans a walk along the Trails, and a saved Route forgets everything but its points. After this phase, in Cycling, a long press plans a Route along the Bike routes the chips allow, never against a one-way line, with its distance and ascent first, a warning from S2 in the direction it is ridden, and, if § 1’s gate passed, “≈ 1 h 40 min” from our own rule. It saves with its Mode and chip, opens in them, replans when either changes, and can be followed on screen. A Bike route’s sheet plans a Route along it and exports it as GPX. The difference a device can be asked about: on the test phone, in Cycling under MTB, a Route from the top of Twister to its foot takes Twister, and one from its foot to its top does not.

PLAN.md moves three things.

• The routes. 7b’s paragraph says the rule is “checked against published riding times for 10–15 of our Bike routes”. § 1 picks 21, tunes on 7 and judges on 7 others, and reads the last 7 only for a second attempt, so 14 are read and up to 21.
• Following in Cycling, on screen, comes forward from 7d: it is 6b’s Following over a ride’s line, and needs nothing 7d adds. 7d keeps what a handlebar needs, the screen kept on and the voice, and its paragraph says so.
• A saved ride’s Mode arrives here, ahead of 7c’s Rides: a ride that can be planned can be saved, and without its Mode it would open as a walk (§ 4).

0. What this phase inherits

• Phase 7a built the Bike routes as data: their edges in trails.network (format 2, each edge’s sets saying Trail, Bike route or both), membership in trails.edges, the way’s own direction for a rider in each edge’s ride byte (oneway:bicycle, else oneway), and mtb:scale and mtb:scale:uphill in edgeMtb and edgeMtbUphill. Since 7a’s B the router keeps a Route in Hiking off an edge without the Trail bit. What it does not store is which kind of Bike route an edge is on, so the chips cannot limit a Route yet, anything about the surface, and the direction a Bike route gives a way: each relation’s sense, from its members’ roles and signed_direction, reaches the build’s edges (Edge.bikes, which walks_like cuts on) and the sheet’s “Ridden one way”, but not trails.network. Some of the 237 Bike routes the sheet calls Ridden one way have no edge the ride byte directs at all, Asfaltový traverz (r2193737) and Żółta Bielawa (r12909385) among them, and more have over a quarter of their walk undirected by it.
• Times are computed at build time. build-network.py’s walking_seconds() writes each edge’s seconds forward and backward from its length and its climb point by point, and the app only adds them, except for a part of an edge, which EdgePart.kt times by a mirror of the same rule. The riding time follows the same path, so the app gains no rule beyond that mirror’s riding half (§ 3).
• A saved Route is its points. RouteEntity holds a name and dates, route_points the points in order, and phase 5 § 5 plans it again on every open. Without a stored Mode a saved ride comes back as a walk. APP_SCHEMA_VERSION is 3.
• 6c’s “Plan a Route along it” and “Export GPX” work on any walk of edges; 7a left them off the Bike route’s sheet for this phase (7a § Not in).
• 6b’s Following is on screen only, timed by the walking Pace, with 6b’s leaving rule as its gate settles it: 40 m for 30 s until then, and still to be read on foot (6b § 1, § 4).
• The switch and the chips are developer-only until 7c (7a), so everything here that a user sees is developer-only too. The migration and the network’s growth reach release builds.

What is in, and what is deliberately not

In: each edge’s surface class, Bike route kinds, rider direction per kind and riding seconds each way, in trails.network format 3; the published riding times for up to 21 Bike routes, and the rule tuned and judged against them; the router in Cycling, along Bike routes only and only the chips’ kind, one-way lines their way; the Route sheet in Cycling with distance and ascent first, the S2 warning and, once the gate has passed, the riding time; a saved Route’s Mode and chip, a migration; the replan when the Mode or the chip changes; Following in Cycling; “Plan a Route along it” and “Export GPX” on a Bike route’s sheet.

Not in, and each with a reason rather than a phase:

• The Pace per Bike. It is learned from Rides, which 7c records. Until then a ride’s time is the rule’s alone, and the walking Pace never touches it: it was learned on foot.
• The screen kept on, and the voice. 7d’s, since they are what makes following on a handlebar different from following on foot. Following itself is not, so it is here.
• A riding time on a Bike route’s sheet. The Trail’s sheet shows no walking time (6c § 3); the sheet says what the route is, and the Route planned along it says how long it takes.
• Telling a ride from a walk in the Routes tab. Only a developer build can save a ride until 7c opens the switch, and the bike glyph lives in app/src/debug/ with the switch. 7c marks the row.
• A physics model, or a time per kind of Bike route. ADR-0011 rejected the first; the amendment below replaces the second.

The tempting one: tuning until the numbers pass. With the references in hand it is easy to keep adjusting the rule and judging it on the same routes until every one is within 20 %. That proves the fit and nothing else. § 1 fixes the split before a single reference is read, judges once, and after a second failure ships no time at all.

Checkpoints

The gate is not first, against the template, because it can veto only G. Planning, saving and following stand without a time (§ 1’s third verdict), so D, E and F do not wait for it; C needs B’s surface class to be tuned at all. A needs no code and starts at once: the references are read before B exists, so nothing in the build can lean on them. G does not merge if C fails twice.

1. The gate: does our riding time land within 20 % of what riders are told elsewhere?

The question, in the form that can be measured

For 7 Bike routes the rule was not tuned on, each in every direction it may be ridden, one for a one-way route and two for the rest, is the median of |estimate − reference| / reference over those directions at most 20 %, and is none above 40 %? The reference for a route and a direction is the midpoint of mapy.cz’s time and Komoot’s at its default fitness for the same line (decided with the owner on 2026-11-11). Official guides’ times are recorded beside them where they exist and counted nowhere: they are scattered, mostly one direction, and written for different riders.

The apparatus

• The routes, picked in A before any reference is read: 21 Bike routes, 9 MTB and 12 Touring, in seven strata of three alike, one kind each, flat or hilly, paved or rough, the strata together spanning Poland, Czechia and Slovakia. Twister (r5738733) and one other one-way trail-centre line share an MTB stratum, so they never land in one set. A seeded shuffle, its seed written in R1, deals each stratum’s three one to tune, one to judge and one to reserve, so each set holds 7 routes, 3 MTB and 4 Touring, and the same mix of ground. A one-way route counts one direction, so a set holds 14 directions less one for each one-way route in it.
• The readings: for each route and direction, the line drawn along its walk in mapy.cz’s planner (cycling) and Komoot’s (touring bike for Touring, mountain bike for MTB, default fitness), its time written down with the distance each gives, to catch a line that strayed. Both are read in the owner’s Chrome through Playwright, said in chat before each session. The reserve is read only after a first failure, so it can influence nothing before it.
• scripts/riding-time.py, on the PC: it imports build-network.py, builds the edges at B’s pin with its own edges_of(), and for each route takes the edges along its walk (7a § 2’s walk) and times them by B’s riding-seconds function with candidate constants, so the rule it judges is the one that ships, on the same densified points and heights (§ 2). It prints the estimate against the reference. --fit tune fits the constants by least squares on log error, each bounded within the published routers’ spread (cycling-research.md § 2); --judge judge prints the median and the worst. The constants it settles go into build-network.py, which scripts/map-archives.py counts among the map data’s inputs, so the first map-data publish after C rebuilds the network with them.

The verdicts, decided now rather than argued about later

Decided with the owner on 2026-11-11:

1. Median ≤ 20 % and none > 40 % on the judge set → the constants are committed and G ships the time.
2. It fails → tune once more, on tune and judge together, and judge on the reserve by the same marks. Pass → as 1.
3. It fails again → no time in Cycling. The Route sheet shows distance and ascent only, G does not merge, and the phase closes on D, E and F. The rule and both comparisons stay recorded in R3. A later attempt that passes the same marks, on routes it was not tuned on, adds the time in its own feat:.

The verdict, taken 2026-11-11

Verdict 1: it passes. Fitted on tune and judged once on judge, the judge set’s median error is 3.2 % and its worst 11.9 %, against marks of 20 % and 40 %. The fitted constants are build-network.py’s RIDING, and G ships the time. The network is not waiting for G: scripts/map-archives.py counts build-network.py among the map data’s inputs, so the first map-data publish after C rebuilds trails.network with the fitted riding seconds, and from then on D, E and F plan on them, still shown nowhere until G. The reserve was never read. R3 has the run.

2. The data

• A surface class per edge: paved, unpaved or rough, from surface where a way has one, else from highway and tracktype, which every way has. The table B starts from, C’s to move a member between classes and say so in R3:

  Class	surface	Else highway / tracktype
  paved	asphalt, concrete*, paving_stones, sett, chipseal, paved, metal, wood	roads, cycleway, service; track with grade1
  unpaved	compacted, fine_gravel, gravel, unpaved, dirt, earth, ground, grass_paver	track with grade2, grade3 or none
  rough	rock, stone, pebblestone, roots, mud, sand, grass, woodchips	path, footway, bridleway, steps; track with grade4, grade5

  On a Bike route a way’s class is part of what makes two pieces one edge (walks_like), so a Bike route’s edge has exactly one. A Trail-only edge is never cut by it and stores its longest piece’s class, which nothing reads. An edge a Trail shares with a Bike route is a Bike route’s edge and is cut like one, so the Hiking network gains 1,049 edges where the class changes along a shared stretch (R2). That Trail-only edges keep 7a’s edges was decided with the owner on 2026-11-11; the cuts on shared edges the owner accepted the same day.

• The Bike route kinds per edge: the sets byte splits 7a’s Bike route bit into Touring and MTB, so an edge on both kinds carries both, and the router can keep to the chips.
• A rider direction per kind, Touring and MTB, a byte each beside ride, folded from every place ADR-0011 reads direction: the way’s oneway:bicycle, else oneway, where it sets one (the ride byte), else the senses of that kind’s Bike routes on the edge, from their members’ roles, signed_direction and the relation’s own oneway (Edge.bikes): one way where every one of them rides it in the same sense, both ways where any of them rides it both ways or two disagree. walks_like already cuts an edge where a route’s sense changes, so each edge has one direction per kind. Under All a direction either kind on the edge allows is open.
• A Bike route relation’s own oneway is read as its sense, beside its members’ roles and signed_direction (decided with the owner on 2026-11-11): yes rides it in its members’ order, as signed_direction=yes does, -1 the reverse, and no says nothing. It reaches Edge.bikes, the rider direction per kind and the sheet’s “Ridden one way”. 21 Bike routes carry it, and 3, Singletrack 14 (r10113028) among them, were ridden both ways without it. Where sources disagree, 7a’s order holds: the way’s own tag, then the member’s role, then the relation, whose signed_direction=yes wins over its oneway.

• Riding seconds forward and backward, computed as walking seconds are, from the same densified points and heights edges_of() measures the climb on, by one function that takes them and the constants (C imports it). A stretch is one of climb()’s runs: from the point the height was last counted at to the next point 5 m or more above or below it, the last run ending at the edge’s end whatever its height differs by there, as climb() counts that rest too. Each run is timed by its length and its change, so the metres a ride’s time climbs are exactly the edge’s ascent, a wobble under 5 m inside a run adds nothing, and a run’s grade is its change over its length. Each stretch at its class’s flat speed, slowed uphill by a time per metre climbed, faster downhill by a factor up to a descent cap per class, and capped below by mtb:scale in the direction ridden (mtb:scale:uphill uphill where it is tagged). No stretch takes longer than walking it: a rider who cannot ride it pushes, timed by walking_seconds()’s rule, the PTTK marker’s, times a pushing factor, so a 15 % push is 2 km/h as on foot rather than a fixed speed that overrides the climb term on every steep stretch. An edge on no Bike route gets none. The starting constants, from cycling-research.md § 2, every one C’s to tune:

  	paved	unpaved	rough
  Flat	20 km/h	15 km/h	10 km/h
  Descent cap	40 km/h	25 km/h	15 km/h

  Climbing 10 s per metre up; descents ×1.5 the flat before the cap; pushing ×1 the walking time. mtb:scale caps at S2 10 km/h, S3 6 km/h, S4 and over 4 km/h: the 4 km/h is GraphHopper’s, which it applies from S3 on; S2’s 10 and S3’s 6 are our own steps down to it, which GraphHopper does not take, and C keeps them only if the routes bear them out.

• trails.network goes to format 3 with the five arrays (the surface class, the two rider directions, the riding seconds each way) and the split bit. The base files’ growth, against 7a’s (trails.network 15,198,240 B, trails.edges 275,796 B), is R2, recorded, not judged: the owner decided on 2026-11-01 that size blocks nothing.

3. Planning in Cycling

• The router plans over the edges the chips allow: in Cycling under All any Bike route edge, under Touring or MTB only that kind’s, and never an edge against that kind’s rider direction (§ 2), so a line directed only by its relation’s roles or signed_direction is planned its way as Twister is. In Hiking it is as it was. The long press, the points, Reverse and the sheet are phase 5’s; Reverse on a Route with a one-way stretch plans whatever the router finds the other way.
• In Cycling it minimises B’s riding seconds, whether or not § 1’s gate passed: a failed gate hides the time, never the cost, so a ride takes a rider’s fastest line rather than a walker’s. A* keeps phase 5’s straight line to the end as its heuristic, at the fastest speed the rule gives anywhere, the highest of the flats and the descent caps, so a refit that leaves a flat above every cap keeps it admissible (19.28 km/h, the paved descent cap, at R3’s constants: every class rides its descents at its cap, and no flat is faster), so it never overestimates and the leg found is the fastest. At phase 5’s 4 km/h it would overestimate a ride about threefold, miss the fastest leg, and misplace 6c § 5’s via points with it. The constants are R3’s from C on, build-network.py’s RIDING: the first map-data publish after C rebuilds trails.network with them (§ 1), whether or not G merges, and G only shows the time. In Hiking the cost and the heuristic are phase 5’s. R3’s tune directions average 9 to 17 km/h, below 19.28 km/h, so the bound is loose and A* may visit more nodes than in Hiking: R5 and R8 time it against phase 5’s and 6c’s marks, and decide whether it needs a tighter one.
• A part of an edge, where a point joins it between its ends, is timed as Hiking times one (EdgePart.kt): the riding rule run over the heights it rides, by its own runs, with the edge’s class and grades, so its time follows the point along the edge rather than taking a share of the edge’s. The app so keeps the riding constants beside the walking ones it already mirrors, build-network.py’s the source, and a test holds the two together (Tests).
• A point off the Bike routes joins as phase 5’s ends join the Trails: every edge the chips allow within 1.5 km is a candidate, and the stretch from the point to it is timed at the rough class’s flat speed (11.60 km/h at R3’s constants, the slowest a rider is assumed to go where nothing is known of the way), counted ten times while the join is chosen and once in the leg’s time, so a farther Bike route wins only for a much shorter Route. It is drawn dashed, and the sheet shows its length over 50 m.
• The Route sheet in Cycling shows distance, ascent and descent, the profile, and the warning; from G the riding time under them, “≈” and rounded to 5 minutes, “< 5 min” under 5, and each point’s time, summed in riding seconds unrounded and rounded as the total. Without G no point shows a time. None of the Pace lines shows in Cycling (route_time_signposts, pace_yours, pace_floored, pace_none): they speak of signposts and hikes, and the walking Pace never touches a ride (Not in). Hiking’s sheet is unchanged.
• The warning: “Includes a demanding stretch” with the hardest grade from S2 up, read per edge in the direction it is ridden: mtb:scale level or downhill, mtb:scale:uphill uphill where it has one, else mtb:scale. An ungraded stretch adds nothing, as 7a’s sheet says nothing.

Copy: “%1$s from the nearest Bike route”, “No way over the Bike routes between %1$s and %2$s”, “Riding time”, “≈ %1$s”, and the warning’s own string, “Includes a demanding stretch: %1$s”, whose argument is 7a’s mtb_grade or mtb_grade_uphill (“S3”, “Uphill S2”) and whose comment says the grade is the MTB scale’s from S2 up. Phase 5’s route_demanding stays Hiking’s: its argument names a stretch by its ends and its comment calls the grade a hiking one. Every other string the Cycling sheet shows names no Trail, hike or signpost and is Hiking’s as it is.

4. A saved ride, and the switch

• A saved Route stores its Mode and its chip: two columns on routes, mode and bikeRouteFilter, enums by name, defaulting to HIKING and ALL, so every Route saved before stays a walk (decided with the owner on 2026-11-11). MIGRATION_3_4, registered, its schema exported, the gate’s assertion and a migration test that proves the rows and their points survive.
• Opening a saved Route sets the map’s Mode and chip to its own and plans it under them, in one step with the Route itself: they are handed to the router with its points rather than read back from the map, and change together with the new Route, so the replan below never runs on the Route being replaced. Opening one while Following ends Following first, as it does today.
• The Routes tab plans a saved Route under its own Mode and chip as well. Its rows (RouteTotals, keyed by the points, the Mode and the chip rather than the points alone) and RoutesViewModel.exportGpx both plan. A ride’s row shows its length with no walking time and no signposts’ Pace, and no time before G; from G it shows the riding time, “≈” and rounded as the sheet rounds it. A ride’s GPX export plans over the Bike routes its chip allows and, with no way, says § 5’s Cycling string. Both read the stored Mode through the map’s own seam (modeOf), so in a release build a ride’s row and export are a walk’s, as it opens (Known gaps).
• Every other caller of the planner passes a Mode and chip too: AppContainer.planRoute takes them beside the points, so nothing can plan a ride as a walk by default. The followed Route kept for a closed app (FollowedRoute, 6b § 3) stores them beside its points, Hiking and All when absent so one stored before this phase decodes as a walk, and resuming sets the map’s Mode and chip to them before it plans, as opening a saved Route does, so an MTB ride never replans over Touring lines under the map’s own chip. The map stores its chip beside its Mode (2026-11-13, the owner’s call), and a chip set by a resumed or opened Route wins over the stored one read at start. “Back to the Route” plans under the followed Route’s (§ 5). The debug seeder’s Hike along a Route stays a walk, and RouteReceiver takes them from --es mode and --es filter (Readings).
• A change of Mode or chip with a Route open replans its points in the new Mode, saved or not. A leg that cannot be joined says so as in § 3. On a saved Route it is an unsaved change, and Save stores the new Mode and chip.
• While Following, the switch and the chips are locked: changing the line under someone on the way helps nobody.
• Settled in E (by the agent, 2026-11-12, kept by the owner the same day). A saved Route with an unsaved change says “Unsaved changes” under its name, in every build, after a point edit as after a switch; the mark clears on Save or delete and is not kept across a closed app. A walk ignores a chip change but saves the map’s chip. Opening a ride writes its Mode and chip to the map’s stored ones, and opening one in the other Mode closes the selection. Its Save button then reads “Save changes”, and the name dialog it opens is titled and confirmed the same, since Save writes over the same Route; with nothing changed, and on a Route never saved, it reads “Save route” (the owner, 2026-11-13).
• Back closes the Route (the owner, 2026-11-13), in every Mode and build, once the sheet is collapsed: an expanded sheet collapses first, a selection or a Hike over it closes before it, and while Following Back leaves the Route alone. “Route closed” with Undo takes the sheet’s place for 5 seconds, or longer where Android’s “Time to take action” asks for it, announced to TalkBack, and Undo puts the Route back as it was, saved or not; a point added meanwhile ends the offer. Before, Back left the app.

5. Following, and a Route along a Bike route

• Following in Cycling is 6b’s: Progress, the line ahead, the distance left, and, from G, the time to go from the riding seconds alone, spread over the line by the riding rule as 6b spreads the walking one. The leaving rule is 6b’s, as its gate settles it (40 m for 30 s until then); “Back to the Route” plans over the Bike routes the chips allow by § 3’s router.
• Progress’s forward window reaches as far as a ride does: 6b’s window is max(200 m, 6 km/h × the time since the last match), so while counted fixes arrive every few seconds a rider never outruns it. It stalls only after a gap in matched fixes, under trees or with the phone in a pocket: at 20 km/h a gap of more than about 36 s carries the rider past 200 m while the window is still 200 m, and the next fix lies beyond it. In Cycling the speed is the rule’s fastest, the highest descent cap (19.28 km/h at R3’s constants), never less than 200 m; in Hiking it stays 6 km/h. That is slower than R9’s scripted 20 km/h: after its 61 s gap the window reaches 327 m and the next fix lies 340 m on, so F settles the window’s speed before R9 is read.
• Settled in F (by the agent, 2026-11-12, kept by the owner the same day). The window keeps the rule’s fastest speed rather than a margin above it. A fix beyond the window’s end still matches wherever the line comes within the leaving distance of it inside the window, at the window’s end itself on a straight line, so R9’s fix 12 m past the window moves Progress, and a ride at 20 km/h outruns the window by more than 40 m only after a gap of about 200 s. A faster descent outruns it sooner: at 30 km/h, after a gap of about 29 s.
• Settled in G (by the agent, 2026-11-12, kept by the owner the same day). “Rounded to 5 minutes” is to the nearest 5, a half up, where a walk’s time rounds up as a signpost’s does. Every riding time shown carries “≈”, and one under 5 minutes reads “< 5 min” instead (the owner, 2026-11-13, for a short leg back that read “≈ 5 min”): the sheet’s total under “Riding time”, each point’s, Following’s next point, end and leg back, and the Routes tab’s row. The leg back in Cycling is timed by its own riding seconds, as a walk’s is by its walking ones. The riding rule spreads a leg’s time over the line by climb()’s runs, each vertex carrying the surface class and mtb:scale of the edge it is reached along, a run also ending where they change, as the build’s runs end with each edge; the line off the Bike routes is the rough class’s. Following’s three lines without a time went with G.
• “Plan a Route along it” on a Bike route’s sheet is 6c § 5’s, over the Bike route’s walk, planned under the route’s own kind: where the current chip excludes it, the chip is set to that kind first, and All stays All. Search in Cycling finds both kinds whatever the chip and a chip change leaves a selection open (7a § 4), so the chip alone would plan an MTB route opened under Touring as “No way” or a detour. The via points are found by § 3’s router under that chip, and the Route saves with it (§ 4). A one-way Bike route is planned its way only; Reverse then plans whatever the router finds the other way, as on a Trail with a one-way stretch. It is not offered while Following, since the chips are locked then (§ 4); a Trail’s sheet keeps 6c’s, where the new Route ends Following, as it changes no chip. The chip changes together with the new Route in one step, as on opening a saved Route (§ 4): the open Route is set aside first and the new one planned under the new chip, so § 4’s replan never runs on the Route being replaced, and a saved one is never marked changed just before it goes.
• “Export GPX” on a Bike route’s sheet is 6c § 5’s, named after its title, with the OSM <copyright> and <link>. It writes the walk and plans nothing, so it has no “no way”; a saved ride’s export from the Routes tab, which plans, has its own (§ 4).

Copy: “Back to the Route from the nearest Bike route, %1$s away”, “No way back to the Route over the Bike routes”, and “This route has no way over the Bike routes right now, so there is no GPX to export.”. Following’s lines without a time, used until G and for good if G never merges: “Next: %1$s · %2$s · ↑ %3$s”, “To the end: %1$s · ↑ %2$s” and “Back to the Route: %1$s”; from G, 6b’s own with the riding time. following_back, “Back to the Route”, holds as it is, its comment gaining the Bike routes beside the Trails.

6. A Bike route’s walk each way it is ridden

R8 found a Route along Główny Karpacki Szlak Rowerowy leaving 18 of its walk’s edges, and 10 the other way: 7a’s walk is one line, ridden both ways on a two-way route, and where a route holds two one-way strands, a dual carriageway each strand of which is a forward member, the longest-path search keeps one strand for both directions. At pin 4965, 297 Bike routes ride an edge against its rider direction, on 1,018 edges, 229.5 km. The walk keeps to the rider direction (the owner, 2026-11-12), one walk each way (the same day).

• Two walks, there and back. A two-way Bike route’s there walk is 7a’s, its start and direction kept; its back walk is the same line turned. In each, every run of edges the rider of the route’s kind may not take that way (ride_touring or ride_mtb) is replaced by the shortest run over the route’s own edges between the same two vertices that the rider may take and that rides no edge the walk already rides. Where there is none, the run widens along the walk a step at a time, up to 250 m past either end (150 m until 2026-11-13, when the owner took R11’s measure of 250), its widened steps replaced with it rather than ridden twice, until a repair fits; where none fits within that, the walk breaks at the run, as 6c’s gaps break it. Both are the owner’s (2026-11-12). Without the bound a loop’s repair is the rest of the loop ridden back: 4020 Okruh Stolové hory’s walk went from 126.8 km to 252.9 km round 414 m of a one-way street. Without the widening a dual carriageway whose other strand leaves one two-way edge before the run, and a roundabout reached by one-way slip roads, broke too: 88 runs on 43 routes at pin 4965. With both, those are repaired, and the rest of a loop, kilometres away, never is. A run whose two ends, widened or not, are one junction is a loop, and its repair is that loop ridden round the other way, where the rider may, never the shortest ride from the junction back to itself, which is none and would leave the loop out (the owner, 2026-11-13). A loop the rider may take neither way round is left out, as before. A one-way route has its there walk only, repaired the same way. A Trail’s walk is as it was: a walker has no direction.
• A roundabout is one-way for a rider. ride() reads junction=roundabout and junction=circular as one-way along the way where no oneway or oneway:bicycle says otherwise, as OSM implies; at pin 4965 an untagged ring counted as two-way. oneway(), the walker’s, is unchanged.
• trails.edges goes to format 2: each row gains a second first-and-count, its back walk, a count of 0 meaning the there walk turned (every Trail, and every Bike route with nothing to repair). The app reads format 2 and refuses 1 by name.
• The there walk is the route’s on screen: the sheet’s length, ascent and descent, the profile, the line below zoom 10 and “Export GPX” are its, so they move where a strand was swapped and where the walk now breaks.
• “Plan a Route along it” holds both walks. A span holds when the leg from its start to its end rides the there walk’s edges between them in order, and the leg back rides the back walk’s between the same two vertices, so a via point stands only where both walks pass, where the strands rejoin. Reverse on the Route sheet then rides the back walk with no new UI and nothing stored. Where a back walk is its own, Reverse plans points found along it, held by the there walk the same way, so it starts where the back walk does: a walk’s last run against the rider can leave the there walk short of an end the back walk reaches, and turning the there Route’s points would leave that stretch unridden (R10’s 461.2 m on r2748517). The points are found with the Route’s and kept in memory only, for as long as the Route stands as planned: an edit, a replan under another Mode or chip, or Save leaves Reverse turning the points, as a saved Route has nothing of its Bike route to plan from (the owner, 2026-11-13). Where the back walk is the there walk turned this is 6c’s rule as it was, and a one-way route keeps its rule of being asked one way only. 6c’s halfway point, for a span no vertex holds, stands only on an edge both walks ride.

Tests

• test_build_network.py: the class of each surface in the table and of each fallback, surface winning over highway; riding seconds on a flat, a climb, a descent reaching its cap, an mtb:scale cap in each direction and a steep push timed as walking it, forward and backward swapping climb and descent; a wobble under 5 m inside a run adding no time, a last run inside the band timed by the change climb() counts for it, and the metres the time climbs equal to the edge’s ascent; the split kinds on a way shared by a Touring and an MTB route; the rider direction per kind from a way’s tag, from a forward role alone, from signed_direction alone, both ways where two routes of a kind disagree, and each kind its own on a way shared by both; a route one way from the relation’s own oneway alone, and oneway=no leaving it two-way (decided with the owner on 2026-11-11, with test_kozica_profile.py reading the sense yes and -1 give); no riding seconds on a Trail-only edge; format 3 written and read back. Fails toward a wrong time, a Route over the wrong kind or one against the ride.
• TrailNetworkTest: format 3 read, and format 2 refused by name.
• The router: in Cycling it keeps off Trail-only edges, off the other kind under a chip, and off a one-way edge backwards, whether the way’s tag directs it or only its Bike route’s role or signed_direction; under All an edge one kind directs and the other does not is open both ways; in Hiking nothing changes. In Cycling it takes a longer paved line over a shorter rough one where riding seconds say so, where Hiking takes the shorter; its heuristic never exceeds a leg’s riding seconds; a point off the Bike routes joins at the rough flat speed, weighted ten times while choosing and once in the time. Fails toward a Route a rider may not take, or a slower one than the network holds.
• EdgePart’s riding half: run over a whole edge’s points, it gives the riding seconds the build stored for that edge, so the app’s mirror cannot drift from build-network.py’s constants; the fixture holds a ride each constant moves, and test_build_network.py fails when one stops moving.
• The sheet’s figures: the time rounded to 5 minutes, “< 5 min” under 5, and each point’s time rounded as it is, none without G; no Pace line in Cycling; the warning from S2 only, uphill read from mtb:scale:uphill where it is tagged, in its own string.
• Following in Cycling: after 60 s with no fix, a fix 340 m on along the line, a ride at 20 km/h, moves Progress, where in Hiking, whose window is then still 200 m, it does not; with fixes every few seconds both keep up; without G, the lines carry no time.
• “Plan a Route along it” on an MTB route under Touring sets the chip to MTB, and under All leaves All. In the map’s ViewModel, with a saved Route open under Touring, it plans only the new Route, once, under MTB, and leaves the saved one unmarked; while Following it is not offered and does nothing.
• The Routes tab’s ViewModel: a saved ride’s row is planned under its Mode and chip and shows its length with no walking time and no Pace, and no time without G; the same points saved as a walk and as a ride are planned apart; a walk’s row is as it was. Its GPX export plans a ride under its chip and, with no way over the Bike routes, fails with the Cycling string.
• FollowedRoute: one stored before this phase decodes as Hiking and All; resuming a followed ride sets the Mode and chip before it plans.
• MIGRATION_3_4 and SchemaGateTest, under the house rule: a v3 database with Routes and points opens at v4 with both intact and every Route HIKING and ALL.
• The map’s ViewModel: a change of Mode or chip replans an open Route and marks a saved one changed; both are refused while Following. Opening a saved ride with a walk open plans only the ride, under its own Mode and chip, and marks nothing changed.
• riding-time.py: its error measure and the split are deterministic from the seed.
• H, test_build_network.py: a two-way route over a pair of one-way strands gets a there walk on one and a back walk on the other, neither riding an edge against the rider; a one-way way with no other strand in the route breaks the back walk there; a one-way route has no back walk and its there walk keeps to its direction; a Trail’s back walk is a count of 0; an untagged roundabout is one-way for a rider and two-way for a walker; format 2 written and read back. Fails toward a walk a rider may not take.
• H, the app: trails.edges format 2 read and 1 refused; “Plan a Route along it” over a pair of strands puts its via points where they rejoin, its Route rides the there walk and its Reverse the back walk; a halfway point never stands on an edge only one walk rides; a Trail’s Route along is as it was.

Documents this phase amends

• ADR-0011: the flat speed is the way’s surface class; a riding time ships only after § 1’s gate; saving a ride is a schema change in 7b, before 7c’s; Following in Cycling is on screen from 7b, its screen kept on and voice from 7d.
• PLAN.md: 7b’s paragraph names this file, the 14 routes read with 7 in reserve, Following on screen and a saved ride’s Mode; 7d’s says on-screen Following arrives in 7b and 7d adds the screen kept on and the voice.
• CONTEXT.md: nothing; see the header.
• The privacy policy and the listing: nothing. The published times are read on the owner’s PC, and nothing in this phase reaches a release user’s screen.

Known gaps, deliberately

• A walk can still break where its route does. § 6 swaps strands over the route’s own edges only: a one-way way with no other strand in the route breaks that direction’s walk, 145.9 km of such edges at pin 4965. Closing them over roads outside the route would add edges the network does not hold.
• A ride saved in a developer build, restored into a release build, opens as a walk, and its row and GPX export in the Routes tab are a walk’s: release builds stay in Hiking until 7c. Its Mode is kept in the row, so it is a ride again once the switch ships, unless it is saved there first: Save in a release build stores the Mode it is open in, Hiking, and it stays a walk.
• The leaving rule is read on foot, if at all. 6b’s gate settles it on walks; if it keeps 40 m for 30 s, that covers several hundred metres at riding speed. 7d, which follows a ride for real, reads it on a ride and changes it only by that reading.
• Surface is OSM’s. A way with no surface is classed by its highway, so an asphalt track tagged with nothing else is timed as unpaved.
• The reference is two planners’ midpoint, not a rider. 7c’s Pace per Bike moves the time toward each rider; until then the time is a first guess, and says so with its “≈”.

Readings

PLAN.md rule 3: filled in as the phase runs, from the device or the PC, with the command that read it. The device readings run on an emulator where it can show them, a debug build with the network hand-pushed to files/network/.

RouteReceiver gains what the readings need, in app/src/debug/ with the rest of it: in D, --es mode CYCLING and --es filter ALL|TOURING|MTB, planning under that Mode and chip as the map would, for R4 and R5; in F, --el bikeRoute <id>, which plans along that Bike route by “Plan a Route along it”’s code from the chip --es filter gives, as the map’s current one, and logs its row and the chip it planned under beside it and the time taken, as --el trail does for a Trail, and the nodes visited, which --el trail does not log, for R8.

R1, the references

The pick and the split. Seven strata of three alike, chosen from 7a’s places.sqlite by kind, climb per kilometre, the surface mix of their member ways and country, each route with no gap in its walk. The seed is 20261111, the date it was taken. The deal: one random.Random(20261111), the strata in the order below, each stratum’s three ids sorted ascending, shuffled, and dealt to tune, judge and reserve in that order. riding-time.py --split 20261111 reproduces it and then applies the one replacement below. The seed put Twister in the reserve; the deal stands.

One replacement, before any of its readings counted. Singletrack 14 (r10113028) was dealt to judge in M3. Its relation is tagged oneway=yes and 18 of its 40 ways are one-way cycleways, so it is ridden one way. 7a gives a route its sense from each member way’s own oneway:bicycle or oneway, then roles and signed_direction, never from the relation’s own oneway; Singletrack 14’s 18 directed ways fall under the 0.75 share (ONE_WAY_SHARE in scripts/build-network.py), so 7a lists it as ridden both ways. Komoot could not draw our walk in either direction, straying 13 % and 68 % with 12 waypoints and 190 % on a half; mapy.com was not tried. The rule was fixed before any candidate was looked at. The two-way MTB route closest to it in climb per kilometre and unpaved share, with no relation oneway and no one-way member, takes its judge slot. That is Rowerowa 500 – G6 (r14354061), and the deal is otherwise unchanged. Twenty more Bike routes carry a relation-level oneway; 7a lists two of them, beside Singletrack 14, as ridden both ways.

How each direction was read. The walk is 7a’s, from trails.edges at 7a’s pin, as a line in the walk’s direction (“walk’s”) or turned (“reverse”). A one-way route counts its walk’s direction only, the direction it is ridden. Each planner was given up to 12 points sampled along that line, every 800 m or every eleventh of it, whichever is longer. Komoot’s planner refuses more than 13. Times and lengths are the planners’ own seconds and metres, taken from their responses:

• Komoot was read logged out, at its default fitness (constitution 3, “Moderate”), as mtb for MTB and touringbicycle for Touring.
• mapy.com was read at its default pace, as Mountain bike (c 123) for MTB and Bicycle touring (c 121, 18 km/h on the flat) for Touring.

A direction whose planned length strayed more than 5 % from our walk’s was read again as two halves of the walk, each with its own 12 points, and the halves summed. That was Okolo Oravskej Jasenice on Komoot (+27.5 % and +6.3 % whole) and G6’s walk’s direction on mapy.com (−8.4 % whole). Every reading in the table is within 4.3 % of our length. Guides’ times were not looked up; they count nowhere. The reserve is not read until a first failure.

What the readings already say. On paved Touring routes the two planners agree within 10 %, and mapy.com is the slower in six of the eight directions. Everywhere else Komoot is the slower: by 7–34 % on MTB and by 9–43 % on unpaved or mixed Touring, the most on the Czech gravel of T2. The midpoint halves that spread, and it is what the gate is judged against.

R3, the gate

The run, once, on 2026-11-11: map-data/network-venv/bin/python scripts/riding-time.py --data map-data/pin-4965 --relief relief/src/main/assets/relief.pmtiles --cache map-data/pin-4965/riding-gate.json --fit tune --judge judge. map-data/pin-4965/ is B’s pin (poland 4965, slovakia 4965, czech-republic 4966) cut again by build-map-data.py’s own functions, its base files byte for byte R2’s. The references are scripts/riding-references.json, R1’s readings, which test_riding_time.py holds to R1’s table. Every walk at B’s pin runs as 7a’s did, from R1’s start and within 0.1 % of its length; each direction is matched by its start and the order of R1’s waypoints along it.

The fit, least squares on log error over tune’s 12 directions, each constant inside the published routers’ spread (cycling-research.md § 2). The bounds, and the starting constants § 2 lists:

A descent cap’s floor is its own class’s flat ×1.10, so a descent is never slower than the flat (§ 2’s “faster downhill”). The start’s 10 s/m lies above every router’s spread and was held to 8.8 before fitting. With both floors binding and the rough cap under ×1.92 its flat, every class rides its descents at its cap: the descent factor changes nothing from ×1.57 up, so its ×1.92 is where the fit stopped, not a value the routes chose. The pushing factor is not borne out either: at 3.22 s/m riding beats pushing on every stretch of tune and judge, so any value from ×0.784 to ×1.5 gives the same estimate on every direction and the same loss, and its ×0.92 too is only where the fit stopped. The mtb:scale caps are not borne out either way by tune; on judge they add 2.5 min to Turbacz’s walk’s direction, which comes out 3.3 % short. No surface was moved between classes.

Every direction’s error, estimate against the midpoint:

Tune: median 3.7 %, worst 7.2 % fitted (46.6 % and 64.1 % at the start). Judge: median 3.2 %, worst 11.9 %. The judge was run once and not looked at before. Its three worst directions, Ludvíkov’s two and Oravská Jasenice’s reverse, are on the unpaved and mixed Touring routes where Komoot was 28–43 % slower than mapy.com, and all three come out short of the midpoint.

What the rule’s shape does, recorded, not changed. A run of climb()’s that falls is a descent however gently it falls, so 5 m lost over a kilometre rides at the descent speed one way and pays the climb the other. At the start’s constants, Chłopy i Pany’s runs under 1 % put 5.9 min between its two directions against the flat, on flat paved country where the planners differ by 0.3 min: the start timed them 61.6 and 57.5 min. The fit pins the paved and unpaved caps at their floor, which closes the gap to 1.3 min and rides every descent there barely faster than the flat, steep ones included. Fitted, the gentle falling runs save no direction more than 2.8 min against the flat (Kłodzko - Bystrzyca Kłodzka’s reverse, 4 %), and the three worst judge directions at most 0.7 min. A grade below which a run is timed as flat would leave the caps free to fit the steep descents; that is the owner’s call.